MCP ਕਨੈਕਟਰਾਂ ਲਈ OpenID ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਿਕਸ
ਮੈਂ ਇਸ ਹਫ਼ਤੇ ਇੱਕ ਰਿਮੋਟ 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 spec ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, OIDC spec ਦੀ ਨਹੀਂ।
ਕਲਾਇੰਟ ਇੱਕ ਅਜਿਹੇ ਦਰਵਾਜ਼ੇ 'ਤੇ ਖੜਕਾਉਂਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਹੈ। ਇਸ ਨੂੰ 404 error ਮਿਲਦਾ ਹੈ ਅਤੇ ਇਹ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਮੇਰੇ ਕੋਲ ਦੋ ਵਿਕਲਪ ਸਨ:
Nginx ਵਿੱਚ ਇੱਕ reverse-proxy redirect ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਇਹ ਇੱਕ ਆਲਸੀ ਫਿਕਸ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਲੌਜਿਕ ਨੂੰ ਤੁਹਾਡੇ ਕੋਡ ਤੋਂ ਬਾਹਰ ਕੱਢ ਕੇ ਤੁਹਾਡੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਅਤੇ ਡਿਪਲਾਈਮੈਂਟ ਦੌਰਾਨ ਇਸ ਦੇ ਟੁੱਟਣ ਦਾ ਖਤਰਾ ਰਹਿੰਦਾ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ। ਇਹ ਬਿਹਤਰ ਤਰੀਕਾ ਹੈ।
ਮੈਂ ਐਪ ਨੂੰ ਪ੍ਰੋਬ (probe) ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਤਿਆਰ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਮੈਂ ਇੱਕ alias ਬਣਾਇਆ ਜੋ OpenID ਪਾਥ ਨੂੰ OAuth authorization ਪਾਥ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ।
ਮੈਂ 308 Permanent Redirect ਦੀ ਵਰਤੋਂ ਕੀਤੀ।
302 redirect ਇੱਕ POST request ਨੂੰ GET request ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। 308 redirect ਸਖ਼ਤ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਨੂੰ ਨਵੇਂ URL 'ਤੇ ਜਾਣ ਅਤੇ ਉਹੀ method ਅਤੇ body ਬਣਾਈ ਰੱਖਣ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਪੱਕੇ ਤੌਰ 'ਤੇ ਹੋਏ ਬਦਲਾਅ (permanent move) ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਇਹ ਸਹੀ ਤਰੀਕਾ ਹੈ।
ਮੈਂ ਇਸ ਨੂੰ ਇੱਕ configuration flag ਦੇ ਪਿੱਛੇ ਵੀ ਰੱਖਿਆ ਹੈ। ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੇਕਰ ਉਹ ਆਪਣੀ OIDC discovery ਚਲਾਉਂਦੇ ਹਨ।
ਕੋਡ ਵਿੱਚ ਅਜਿਹਾ ਕਰਕੇ, ਮੈਂ ਟੈਸਟ ਲਿਖ ਸਕਦਾ ਹਾਂ:
- ਇੱਕ ਟੈਸਟ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਰੀਡਾਇਰੈਕਟ ਸਹੀ ਤਰ੍ਹਾਂ ਹੋ ਰਿਹਾ ਹੈ।
- ਇੱਕ ਟੈਸਟ ਰੀਡਾਇਰੈਕਟ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ metadata ਵੈਲਿਡ ਹੈ।
ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਜੇਕਰ metadata structure ਬਦਲਦਾ ਹੈ, ਤਾਂ ਮੇਰੇ ਟੈਸਟ ਤੁਰੰਤ ਫੇਲ ਹੋ ਜਾਣਗੇ। ਮੈਨੂੰ ਗਲਤੀ ਆਪਣੇ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਮਿਲ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਉਦੋਂ ਜਦੋਂ ਕੋਈ ਉਪਭੋਗਤਾ ਕਨੈਕਟ ਨਹੀਂ ਕਰ ਪਾਉਂਦਾ।
ਅਕਸਰ ਅਭਿਆਸ ਵਿੱਚ specs ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਭਾਵੇਂ ਦੋ ਸਟੈਂਡਰਡਸ ਦੇ ਉਦੇਸ਼ ਸਮਾਨ ਹੋਣ, ਕਲਾਇੰਟਸ ਵੱਖ-ਵੱਖ ਪਾਥ ਚੁਣਨਗੇ। ਇੱਕ ਸਰਵਰ ਡਿਵੈਲਪਰ ਵਜੋਂ, ਤੁਹਾਨੂੰ ਦੋਵਾਂ ਦਰਵਾਜ਼ਿਆਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ।
ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਕਮਰੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ, ਸਹੀ ਰੀਡਾਇਰੈਕਟ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਟੈਸਟਾਂ ਨਾਲ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰੋ।