𝗧𝗵𝗲 𝗢𝗽𝗲𝗻𝗜𝗗 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 𝗙𝗶𝘅 𝗙𝗼𝗿 𝗠𝗖𝗣 𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗼𝗿𝘀
ఈ వారం ఒక రిమోట్ MCP కనెక్టర్ను సరిచేయడానికే నేను చాలా సమయం వెచ్చించాను.
నా OAuth సర్వర్ను కనెక్టర్ కనుగొనడంలో నిరంతరం విఫలమవుతోంది. సర్వర్ సరిగ్గా పనిచేస్తోంది. సమస్య కేవలం ఒక మిస్ అయిన రూట్ (route) మరియు రీడైరెక్ట్ (redirect) వల్ల వచ్చింది.
మీరు MCPతో OAuthని ఉపయోగించినప్పుడు, డిస్కవరీ డాక్యుమెంట్లు (discovery documents) పనిచేస్తాయని మీరు ఆశిస్తారు. చాలా టూల్స్ ఈ రెండు పాత్ల కోసం వెతుకుతాయి:
- /.well-known/oauth-authorization-server
- /.well-known/oauth-protected-resource
ఇవి అథరైజేషన్ (authorization) మరియు టోకెన్ ఎండ్పాయింట్లను (token endpoints) ఎక్కడ కనుగొనాలో క్లయింట్లకు తెలియజేస్తాయి.
సమస్య ఏమిటంటే, చాలా క్లయింట్లు ఆ నిర్దిష్ట పాత్ల కోసం వెతకరు. దానికి బదులుగా, వారు /.well-known/openid-configuration కోసం వెతుకుతారు.
ఇది ఒక OpenID Connect పాత్. ఇది వేరొక స్పెసిఫికేషన్ (spec), కానీ ఇది కూడా అదే చోట ఉంటుంది. నా ప్యాకేజీ OAuth స్పెసిఫికేషన్ను అనుసరిస్తుంది కానీ OIDC స్పెసిఫికేషన్ను అనుసరించదు, అందుకే ఇది ఈ పాత్ను రిజిస్టర్ చేయలేదు.
క్లయింట్ లేని తలుపును తడుతుంది. దీనివల్ల 404 ఎర్రర్ వచ్చి ప్రక్రియ ఆగిపోతుంది.
నాకు రెండు ఎంపికలు ఉన్నాయి:
Nginxలో రివర్స్-ప్రోక్సీ రీడైరెక్ట్ను ఉపయోగించడం. ఇది ఒక సులభమైన (lazy) పరిష్కారం. ఇది మీ లాజిక్ను కోడ్ నుండి మౌలిక సదుపాయాల (infrastructure) వైపు మారుస్తుంది. దీనిని టెస్ట్ చేయడం కష్టం మరియు డిప్లాయ్మెంట్ సమయంలో తప్పులు జరిగే అవకాశం ఉంది.
అప్లికేషన్ లోపలే దీనిని సరిచేయడం. ఇదే మెరుగైన మార్గం.
అప్లికేషన్ ఆ అభ్యర్థనకు (probe) సమాధానం ఇచ్చేలా చేయాలని నేను నిర్ణయించుకున్నాను. నేను OpenID పాత్ను OAuth అథరైజేషన్ పాత్కు రీడైరెక్ట్ చేసే ఒక ఏలియాస్ (alias)ను సృష్టించాను.
నేను 308 Permanent Redirectను ఉపయోగించాను.
302 రీడైరెక్ట్ అనేది POST రిక్వెస్ట్ను GET రిక్వెస్ట్గా మార్చవచ్చు. కానీ 308 రీడైరెక్ట్ చాలా కచ్చితమైనది. ఇది క్లయింట్ను కొత్త URLకి వెళ్లమని మరియు అదే మెథడ్ (method) మరియు బాడీని (body) కొనసాగించమని చెబుతుంది. శాశ్వత మార్పును (permanent move) నిర్వహించడానికి ఇది సరైన పద్ధతి.
నేను దీనిని ఒక కాన్ఫిగరేషన్ ఫ్లాగ్ (configuration flag) వెనుక కూడా ఉంచాను. దీనివల్ల వినియోగదారులు తమ స్వంత OIDC డిస్కవరీని ఉపయోగిస్తుంటే, దీనిని ఆఫ్ చేసుకోవచ్చు.
కోడ్లో ఇలా చేయడం వల్ల, నేను టెస్ట్లను వ్రాయగలను:
- రీడైరెక్ట్ సరిగ్గా జరుగుతుందో లేదో ఒక టెస్ట్ తనిఖీ చేస్తుంది.
- మెటాడేటా (metadata) చెల్లుబాటు అవుతుందో లేదో నిర్ధారించడానికి మరొక టెస్ట్ రీడైరెక్ట్ను అనుసరిస్తుంది.
దీనివల్ల మెటాడేటా స్ట్రక్చర్ మారితే, నా టెస్ట్లు వెంటనే ఫెయిల్ అవుతాయి. వినియోగదారు కనెక్ట్ కాలేకపోయే సమయం వరకు వేచి చూడకుండా, నా పైప్లైన్లోనే నేను తప్పును గుర్తించగలను.
ప్రాక్టికల్గా స్పెసిఫికేషన్లు తరచుగా భిన్నంగా ఉంటాయి. రెండు ప్రమాణాలు (standards) ఒకే విధమైన లక్ష్యాలను కలిగి ఉన్నప్పటికీ, క్లయింట్లు వేర్వేరు పాత్లను ఎంచుకోవచ్చు. ఒక సర్వర్ డెవలపర్గా, మీరు రెండు తలుపులకు సమాధానం ఇవ్వాలి.
వాటిని ఒకే చోటికి మళ్లించండి, సరైన రీడైరెక్ట్ కోడ్ను ఉపయోగించండి మరియు టెస్ట్లతో దానిని ధృవీకరించండి.