প্রক্সির মাধ্যমে OmniAuth লগইন অনুসরণ

ব্যবহারকারী “সাইন ইন” ক্লিক করে প্রোভাইডারের পৃষ্ঠায় পৌঁছায় এবং Rails-এ ফিরে আসে। পরের ধাপটি তবুও ব্যর্থ হতে পারে, কারণ এটি Rails সার্ভার থেকে নতুন সংযোগ শুরু করে।

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

ব্রাউজার নিজের নেটওয়ার্ক কনফিগারেশন ব্যবহার করে অনুমোদনের রিডাইরেক্ট অনুসরণ করে। Rails ইনস্টল করা OmniAuth স্ট্র্যাটেজি যে HTTP ক্লায়েন্ট বেছে নিয়েছে সেটি দিয়ে ব্যাকচ্যানেল টোকেন বিনিময় সম্পন্ন করে। কর্পোরেট প্রক্সির পেছনে চলা ওয়ার্কারের প্রোভাইডারের অনুরোধে সেই পথটি দরকার।

OAuth 1.0-এ ব্যবহারকারী অনুমতি দেওয়ার আগে সার্ভার-সাইডে অনুরোধ-টোকেনের একটি ধাপও থাকে। OAuth 2.0-এর অনুমোদন-কোড প্রবাহে কলব্যাকের পরে নিজস্ব টোকেন বিনিময় থাকে। সঠিক ক্রমটি স্ট্র্যাটেজির উপর নির্ভর করে, তবে ব্রাউজার ও অ্যাপ্লিকেশন সার্ভার আলাদা শুরুর বিন্দু হয়েই থাকে।

ক্লায়েন্টের কনফিগারেশন খুঁজুন

স্ট্র্যাটেজি অনুসরণ করে সেই HTTP ক্লায়েন্টে যান যা এর টোকেন ও প্রোভাইডার API অনুরোধ পাঠায়। সেই ক্লায়েন্টের নথিভুক্ত প্রক্সি অপশন ব্যবহার করুন। কিছু স্ট্র্যাটেজি ক্লায়েন্ট অপশন OAuth লাইব্রেরিতে পাঠায়; অন্যরা তার নিচে HTTP সংযোগ কনফিগার করে। একটি স্ট্র্যাটেজি যে অপশন গ্রহণ করে সেটি স্বয়ংক্রিয়ভাবে OmniAuth-এর সাধারণ অপশন নয়।

প্রোভাইডারের অনুমোদন, টোকেন ও কলব্যাক URL তাদের প্রকৃত পরিষেবাগুলোই বর্ণনা করতে থাকুক। আউটবাউন্ড প্রক্সি হলো প্রোভাইডারে পৌঁছানোর পরিবহন সেটিং, এটি কলব্যাক ঠিকানার বিকল্প বা OAuth অনুরোধের প্যারামিটারে যোগ করার ক্ষেত্র নয়।

লগইন অনুসরণ করার সময় শেষ সম্পন্ন ধাপটি চিহ্নিত করুন। প্রদর্শিত প্রোভাইডার লগইন পৃষ্ঠা প্রমাণ করে ব্রাউজারের পথটি কাজ করেছে। Rails যে কলব্যাক পেয়েছে তা প্রমাণ করে ব্রাউজার ফিরে এসেছে। এর পরের টোকেন অনুরোধই হলো Rails প্রক্রিয়া থেকে আসা প্রক্সি সংযোগ, চ্যালেঞ্জ বা প্রোভাইডারের সাড়া যাচাই করার জায়গা।