Magento-ს გადამისამართების ციკლი, სავარაუდოდ, VPN-ის ბრალი არ არის

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

302 ამბობს სად, და არა რატომ

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

არც ერთი მათგანი VPN-ის შესახებ მტკიცებულება არ არის. გვირაბი გზაა; გადამისამართება აპლიკაციის დაწერილი მითითებაა.

დააფიქსირეთ ჯაჭვი და არა ჟურნალის ხაზი

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

შეინახეთ ეს ჩანაწერი კონფიდენციალურად. URL-ები სესიის იდენტიფიკატორებს ატარებს, ხოლო შენახული ბრაუზერის არქივი იმაზე მეტს ატარებს, ვიდრე ელოდებით. ამოიღეთ მოთხოვნის სტრიქონები, სანამ რამეს ბილეთში ჩასვამთ.

აპლიკაციის წარმოდგენა საკუთარ URL-ზე

Magento აბსოლუტურ URL-ებს კონფიგურაციიდან ქმნის, ვებსაიტის ან მაღაზიის ხედის მიხედვით შემოსაზღვრულს. bin/magento config:show web/secure/base_url ბეჭდავს მნიშვნელობას, რომლისიც აპლიკაციას სჯერა და ეს ხშირად ბილდის ან მიგრაციისგან დარჩენილი ჰოსტის სახელია და არა ის, რომელიც ბრაუზერმა გამოიყენა. თუ იქ შიდა ჰოსტია დასახელებული, ბრაუზერი იქ იგზავნება, სადაც ვერ მოხვდება და გვირაბის არც ერთი ცვლილება არ ასწორებს ამას.

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

სანდო პროქსის თავსართები ხელშეკრულებაა

როცა TLS დატვირთვის გამანაწილებელზე მთავრდება, აპლიკაცია ჩვეულებრივ HTTP-ს ხედავს და პირიქით უნდა უთხრან. offloader-ის თავსართის პარამეტრი ასახელებს იმ თავსართს, რომელსაც პროქსი ადგენს, მაგალითად გადაგზავნილ პროტოკოლს და აპლიკაცია სქემის გადაწყვეტილებებში მას ენდობა.

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

როცა ციკლი სესიაა და არა მარშრუტი

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

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