MCP کنیکٹرز کے لیے OpenID کنفیگریشن کا حل
میں نے اس ہفتے ایک ریموٹ MCP کنیکٹر کو ٹھیک کرنے میں بہت زیادہ وقت صرف کیا۔
کنیکٹر میرے OAuth سرور کو تلاش کرنے میں بار بار ناکام ہو رہا تھا۔ سرور بالکل ٹھیک کام کر رہا تھا۔ مسئلہ صرف ایک مسنگ روٹ (missing route) اور ایک ری ڈائریکٹ (redirect) کا تھا۔
جب آپ MCP کے ساتھ OAuth استعمال کرتے ہیں، تو آپ توقع کرتے ہیں کہ discovery documents کام کریں۔ زیادہ تر ٹولز ان دو راستوں (paths) کو تلاش کرتے ہیں:
- /.well-known/oauth-authorization-server
- /.well-known/oauth-protected-resource
یہ کلائنٹس کو بتاتے ہیں کہ authorization اور token endpoints کہاں تلاش کرنے ہیں۔
مسئلہ یہ ہے کہ بہت سے کلائنٹس ان مخصوص راستوں کو تلاش نہیں کرتے۔ اس کے بجائے، وہ /.well-known/openid-configuration کو تلاش کرتے ہیں۔
یہ ایک OpenID Connect پاتھ ہے۔ یہ ایک مختلف spec ہے، لیکن یہ اسی جگہ موجود ہے۔ میرے پیکیج نے اس پاتھ کو رجسٹر نہیں کیا تھا کیونکہ یہ OAuth spec پر عمل کرتا ہے، نہ کہ OIDC spec پر۔
کلائنٹ ایک ایسے دروازے پر دستک دیتا ہے جو موجود ہی نہیں ہے۔ اسے 404 error ملتا ہے اور وہ رک جاتا ہے۔
میرے پاس دو انتخاب تھے:
Nginx میں reverse-proxy redirect کا استعمال کرنا۔ یہ ایک سست حل (lazy fix) ہے۔ یہ آپ کے لاجک کو آپ کے کوڈ سے نکال کر آپ کے انفراسٹرکچر میں منتقل کر دیتا ہے۔ اسے ٹیسٹ کرنا مشکل ہے اور ڈیپلائمنٹ کے دوران اس کے ٹوٹنے کا امکان زیادہ ہوتا ہے۔
ایپلی کیشن کے اندر اسے ٹھیک کرنا۔ یہ بہتر طریقہ ہے۔
میں نے ایپ کو اس پروب (probe) کا جواب دینے کے لیے تیار کرنے کا انتخاب کیا۔ میں نے ایک alias بنایا جو OpenID پاتھ کو OAuth authorization پاتھ پر ری ڈائریکٹ کرتا ہے۔
میں نے 308 Permanent Redirect کا استعمال کیا۔
302 redirect ایک POST request کو GET request میں تبدیل کر سکتا ہے۔ 308 redirect سخت (strict) ہوتا ہے۔ یہ کلائنٹ کو بتاتا ہے کہ نئے URL پر جائیں اور وہی میتھڈ (method) اور باڈی (body) برقرار رکھیں۔ مستقل منتقلی (permanent move) کو سنبھالنے کا یہی درست طریقہ ہے۔
میں نے اسے ایک configuration flag کے پیچھے بھی رکھا۔ اس سے صارفین کو یہ سہولت ملتی ہے کہ اگر وہ اپنی OIDC discovery چلا رہے ہوں تو اسے بند کر سکیں۔
کوڈ میں ایسا کرنے سے، میں ٹیسٹ لکھ سکتا ہوں:
- ایک ٹیسٹ چیک کرتا ہے کہ آیا ری ڈائریکٹ صحیح طریقے سے ہو رہا ہے۔
- ایک ٹیسٹ ری ڈائریکٹ کا پیچھا کرتا ہے تاکہ اس بات کو یقینی بنایا جا سکے کہ metadata درست ہے۔
اس سے یہ یقینی بنتا ہے کہ اگر metadata کا ڈھانچہ تبدیل ہوتا ہے، تو میرے ٹیسٹ فوری طور پر فیل ہو جائیں گے۔ مجھے غلطی اپنے پائپ لائن (pipeline) میں مل جائے گی بجائے اس کے کہ مجھے تب ملے جب کوئی صارف کنیکٹ نہ کر پا رہا ہو۔
عملی طور پر specs اکثر مختلف ہوتے ہیں۔ یہاں تک کہ جب دو معیارات (standards) کے مقاصد ملتے جلتے ہوں، تب بھی کلائنٹس مختلف راستے منتخب کریں گے۔ ایک سرور ڈویلپر کے طور پر، آپ کو دونوں دروازوں کے جواب دینے چاہئیں۔
انہیں ایک ہی کمرے کی طرف اشارہ کریں، صحیح ری ڈائریکٹ کوڈ استعمال کریں، اور ٹیسٹ کے ذریعے اسے یقینی بنائیں۔