VPN დაკავშირებულია, მაგრამ შერეული კონტენტი ჯერ კიდევ დაბლოკილია: რა უნდა გამოსწორდეს

გვერდის ნახევარი რენდერდება, ერთი სტილის ფურცელი ნაცრისფრად რჩება ქსელის პანელში, და VPN კლიენტი კვლავ იტყობინება ჯანსაღ გვირაბზე. სამივე დაკვირვება ერთდროულად მართალია, რადგან ბრაუზერმა განსაჯა გვერდის მიერ გაკეთებული მოთხოვნა და გვირაბს ამ განაჩენში ხმა არ ჰქონდა. საქმეს ხურავს გადაწყვეტილება და არა პარამეტრი: მითითების გასწორება, მისი ჰოსტის მფლობელამდე აწევა, ან დამოკიდებულებაზე უარის თქმა. თითოეულ ამ ვარიანტს იაფი გამოცდა აქვს, და არასწორის არჩევა ერთ მხარდაჭერის ციკლს ხარჯავს.

რატომ ვერ დაფარავს გვირაბი ქვე-რესურსს

შერეული კონტენტი იწყება HTTPS დოკუმენტით, რომელიც ქვე-რესურსს ითხოვს ჩვეულებრივი HTTP-ით. ყოველი URL საკუთარი სქემით განისაჯება, ამიტომ მშობელი დოკუმენტის დაცვა არასოდეს ვრცელდება შვილობილ მოთხოვნაზე. ბრაუზერის ქვეშ დამატებული დაშიფვრა ცვლის იმას, რაც მავთულზე გადის, და არა იმ http://-ს, რომელიც ნიშნულმა მოითხოვა.

თანამედროვე ბრაუზერები ამ მოთხოვნებს ორ ჯგუფად ჰყოფენ და სხვადასხვანაირად ეპყრობიან. სკრიპტები, სტილის ფურცლები, iframe-ები და fetch, XMLHttpRequest ან WebSocket-ით გამოძახებები მაშინვე უარყოფილია, წინასწარი განახლების მცდელობის გარეშე. სურათები, აუდიო და ვიდეო გადაიწერება https://-ზე და ხელახლა ითხოვება, და ჩატვირთვა წყდება, როცა ეს უსაფრთხო მოპოვება ვერ ხერხდება. ქვე-რესურსის URL, რომლის ჰოსტი შიშველი IP მისამართია, განახლებისგან თავისუფალია, ამიტომ IP ჰოსტზე HTTP სურათი დაბლოკილი რჩება ჩუმად გასწორების ნაცვლად. ეს დაყოფა, მათ შორის ეს გამონაკლისი განახლებად მხარეს, დოკუმენტირებულია Mozilla-ს შერეული კონტენტის სახელმძღვანელოში. Chrome მსგავს უარის თქმას იყენებს უსაფრთხო გვერდიდან დაწყებულ არაუსაფრთხო ჩამოტვირთვებზე, ამიტომ PDF ბმული შეიძლება მოკვდეს, სანამ გარშემო გვერდი ხელუხლებლად გამოიყურება.

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

დაადგინეთ, ვის ეკუთვნის არაუსაფრთხო მითითება

დაალაგეთ პრობლემური URL იმის მიხედვით, სად იქმნება ის, სანამ რამეს შეცვლით. ეს პასუხი წყვეტს, შეგიძლიათ დღეს გამოუშვათ შესწორება, მომწოდებელმა უნდა გამოუშვას ერთი, თუ დამოკიდებულებამ უნდა დატოვოს გვერდი. წაიკითხეთ ის ქსელის პანელის Initiator სვეტში, რადგან ეკრანზე არსებული ნიშნული ხშირად გაშვების დროს იკრიბება.

როცა ჰოსტი უკვე პასუხობს 443-ზე და მხოლოდ მითითება ამბობს http, შესწორება ლოკალურია: შეცვალეთ მითითება, გაასუფთავეთ გვერდის ქეში და დაადასტურეთ, რომ სტრიქონი ხდება https. ჰოსტი, რომელიც მხოლოდ 80 პორტზე ისმენს, რედაქტირებით ვერ დაემთხვევა, ამიტომ რესურსი გადადის, მის წინ დგება თქვენ მიერ კონტროლირებადი რამ, ან ის ქრება. ტეგების მენეჯერის მიერ ჩასმული URL კვლავ ჩნდება მაშინაც კი, როცა თქვენი შაბლონი სუფთაა, და ეს შემთხვევა ეკუთვნის ბილეთს ზუსტი URL-ით და კონსოლის სტრიქონით დართული. პერსონალისთვის იმის თქმა, რომ დაუშვან არაუსაფრთხო კონტენტი, ამ ვარიანტებიდან არც ერთი არ არის, რადგან ეს გამორთავს შემოწმებას ყოველი საიტისთვის, რომელსაც ეს ბრაუზერის პროფილი სტუმრობს.

გაასწორეთ მითითება და არა ბრაუზერის პარამეტრი

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

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

ორი დამხმარე კონტროლი ღირს ცოდნად და არც ერთი არ ცვლის შესწორებას. Content-Security-Policy სათაური upgrade-insecure-requests აიძულებს ბრაუზერს გადაწეროს http ქვე-რესურსების URL-ები სანამ გვერდს დატოვებენ, რაც იჭერს ძველ მითითებებს, რომლებიც ჯერ არ გიპოვიათ. გადაწერილი მოთხოვნა მაინც ვერ ხერხდება, როცა სამიზნე ჰოსტი HTTPS-ს არ ემსახურება, ამიტომ სათაური მხოლოდ იმას ცვლის, რომელ URL-ს ცდილობს ბრაუზერი. HSTS მოქმედებს თითოეულ ჰოსტზე, რაც ნიშნავს, რომ პოლიტიკა თქვენს საკუთარ დომენზე არაფერს აკეთებს მესამე მხარის CDN-ისთვის, რომელსაც ეს სათაური არასდროს გაუგზავნია. შაბლონის შეცვლის შემდეგ გაასუფთავეთ გვერდის ქეში და რენდერდ HTML-ში მოძებნეთ ჰოსტის ძველი სახელი, რადგან იგივე URL შეიძლება მოვიდეს ნაწილის, თარგმანის სტრიქონის ან მონაცემთა ბაზის ველის მეშვეობითაც.

თვალყური ადევნეთ გადამისამართებებსაც, რადგან https://-ით დაწყებული ჯაჭვი შეიძლება http:// ადგილას დაეშვას და ბრაუზერი ბოლო ნახტომს განსჯის. მეორე ბრძანების -L ფორმა ზემოთ ბეჭდავს იმ ეფექტურ URL-ს თქვენთვის. თუ ბოლო ნახტომი სუფთა http-ია, მითითება კვლავ არასწორია, თუმცა თქვენ მიერ რედაქტირებული ბმული კარგად გამოიყურებოდა.

დაადასტურეთ გვერდი კონსოლით და ქსელის პანელით

ხელახლა ჩატვირთეთ გამორთული ქეშით და კვლავ გაიარეთ ნაკადი, მათ შორის ღილაკები, რომლებიც კონტენტს მოთხოვნით ტვირთავს. გვერდის პირველი ჩატვირთვა მალავს ზარმაც ვიჯეტებს, რუკის ფილებს და დამკვრელის სკრიპტებს, რომლებიც მხოლოდ დაწკაპუნების შემდეგ ჩნდება. კონსოლს არ უნდა ჰქონდეს შერეული კონტენტის ჩანაწერები და თქვენ მიერ შეხებულ ყოველ სტრიქონს უნდა აჩვენოს https. დააფიქსირეთ კონსოლი და მოთხოვნის სტრიქონი ბილეთის დახურვამდე, რადგან ამ მდგომარეობის ხელახლა აწყობა შემდეგი განთავსების შემდეგ რთულია.

როცა რესურსი სხვას ეკუთვნის, გაგზავნეთ ოთხი რამ: ზუსტი URL, მოთხოვნის ტიპი, კონსოლის ტექსტი და გვერდი, სადაც ის ჩნდება. დაფარეთ სესიის იდენტიფიკატორები ყველაფერში, რასაც ბილეთში აკრავთ. ანგარიში, რომელიც მხოლოდ ამბობს, რომ სურათები გატეხილია, მფლობელს საძებნელად არაფერს აძლევს.

გვირაბი აგრძელებს თავის საქმეს, სანამ შესწორება იმ მითითებაშია, რომელმაც მოთხოვნა შექმნა. განთავსების შემდეგ კიდევ ერთხელ მოძებნეთ ჰოსტის სახელი შაბლონში და მომწოდებლის პაკეტში, და დახურეთ საქმე მხოლოდ მაშინ, როცა კონსოლში დაბლოკილი შერეული კონტენტის ჩანაწერი აღარ დარჩება.