OmniAuth-ით შესვლის კვალდაკვალ გავლა პროქსის მეშვეობით

მომხმარებელი აჭერს „შესვლას“, აღწევს პროვაიდერის გვერდზე და ბრუნდება Rails-ში. შემდეგი ნაბიჯი მაინც შეიძლება ჩავარდეს, რადგან ის Rails-ის სერვერიდან ახალ კავშირს ხსნის.

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

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

OAuth 1.0-საც აქვს სერვერის მხარეს მოთხოვნის ტოკენის ნაბიჯი მანამ, სანამ მომხმარებელი წვდომას ავტორიზებს. OAuth 2.0-ის ავტორიზაციის კოდის ნაკადს callback-ის შემდეგ საკუთარი ტოკენის გაცვლა აქვს. ზუსტი თანმიმდევრობა სტრატეგიაზეა დამოკიდებული, მაგრამ ბრაუზერი და აპლიკაციის სერვერი კვლავ სხვადასხვა საწყის წერტილად რჩება.

იპოვეთ კლიენტის კონფიგურაცია

მიჰყევით სტრატეგიას იმ HTTP კლიენტამდე, რომელიც აგზავნის მის ტოკენსა და პროვაიდერის API მოთხოვნებს. გამოიყენეთ ამ კლიენტის დოკუმენტირებული პროქსის პარამეტრი. ზოგი სტრატეგია კლიენტის პარამეტრებს OAuth ბიბლიოთეკას გადასცემს; ზოგი მის ქვეშ HTTP კავშირს აყენებს. ერთი სტრატეგიის მიერ მიღებული პარამეტრი ავტომატურად OmniAuth-ის საერთო პარამეტრი არ არის.

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

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