QGIS იყენებს პროქსის, მაგრამ Requests-ზე დაფუძნებული დანამატი — არა

რუკის ფენა იტვირთება ოფისის პროქსის მეშვეობით, მაშინ როცა დანამატის API გამოძახება ვერ ხერხდება. ორივე მოქმედება QGIS-ის შიგნით სრულდება, მაგრამ შეიძლება სხვადასხვა HTTP კლიენტი გამოიყენონ.

QGIS ქსელური ოპერაციებისთვის გამოფენს QgsNetworkAccessManager-ს. ის QGIS-ის ქსელურ კონფიგურაციას გადააქვს ამ მენეჯერის მეშვეობით გაგზავნილ მოთხოვნებში. Python დანამატი, რომელიც Requests-ს იმპორტავს, ქმნის სხვა კლიენტს საკუთარი პროქსისა და ავთენტიფიკაციის ქცევით.

აირჩიეთ კონფიგურაცია, რომლის გაზიარებაც გსურთ

დანამატისთვის, რომელიც მომხმარებლის QGIS ქსელურ პარამეტრებს უნდა მიჰყვეს, QGIS-ის ქსელური მენეჯერის გამოყენება თავიდან აირიდებს ამ პარამეტრების დამოუკიდებლად თავიდან აწყობას. შეამოწმეთ თქვენ მიერ მხარდაჭერილი QGIS ვერსიისთვის შესაბამისი API, მათ შორის მისი ასინქრონული ქცევა და ავთენტიფიკაციის ინტეგრაცია.

თუ Requests სხვა მიზეზით არის საჭირო, შეგნებულად დააკონფიგურირეთ. მისი პროქსის ლექსიკონი და გარემოს დამუშავება მიჰყვება Requests-ის დოკუმენტაციას. QGIS-ის პარამეტრებში არჩეული პროქსი ავტომატურად არ არის Requests სესიის პარამეტრი.

იყავით ზუსტი ფარგლებში, როცა ფორუმიდან Qt-ის მაგალითებს ცდით. Qt აპლიკაციის პროქსის დაყენება გავლენას ახდენს Qt-ის ქსელზე. ეს არ ამტკიცებს, რომ Requests-მა, რომელიც სხვა ქსელურ იმპლემენტაციას იყენებს, შეცვალა თავისი მარშრუტი.

შეადარეთ იგივე დანიშნულება

ქცევის შედარებისას გამოიყენეთ წარუმატებელი დანამატის URL. რუკის სერვისსა და დაუკავშირებელ API-ს შეიძლება ჰქონდეს სხვადასხვა გვერდის ავლის წესები, პროქსის ნებართვები ან სერტიფიკატების ჯაჭვები. წარმატებული რუკის მოთხოვნა მხოლოდ იმას ამტკიცებს, რომ მისი საკუთარი მარშრუტი მუშაობს.

ჩაწერეთ HTTP კლიენტის სახელი, დანიშნულების ჰოსტი, მოითხოვეს თუ არა პროქსის ავთენტიფიკაცია და შეცდომის რეალური ეტაპი. გამორიცხეთ პაროლები დანამატის ჟურნალებიდან. ეს მცირე შედარება ჩვეულებრივ გეუბნებათ, გამოასწოროთ QGIS-ის ქსელური ინტეგრაცია თუ დამოუკიდებელი Python კლიენტი, იმ პროქსის პარამეტრების გადატვირთვის გარეშე, რომლებიც მომხმარებლისთვის უკვე მუშაობს.