MCP ಕನೆಕ್ಟರ್‌ಗಳಿಗಾಗಿ OpenID ಕಾನ್ಫಿಗರೇಶನ್ ಪರಿಹಾರ

ಈ ವಾರ ಒಂದು ರಿಮೋಟ್ MCP ಕನೆಕ್ಟರ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ನಾನು ತುಂಬಾ ಸಮಯವನ್ನು ವ್ಯಯಿಸಿದೆ.

ಕನೆಕ್ಟರ್ ನನ್ನ OAuth ಸರ್ವರ್ ಅನ್ನು ಹುಡುಕಲು ವಿಫಲವಾಗುತ್ತಿತ್ತು. ಸರ್ವರ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಸಮಸ್ಯೆ ಎಂದರೆ ಕೇವಲ ಒಂದು ಮಿಸ್ಸಿಂಗ್ ರೂಟ್ (missing route) ಮತ್ತು ರಿಡೈರೆಕ್ಟ್ (redirect).

ನೀವು MCP ಜೊತೆಗೆ OAuth ಬಳಸಿದಾಗ, discovery ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನೀವು ನಿರೀಕ್ಷಿಸುತ್ತೀರಿ. ಹೆಚ್ಚಿನ ಪರಿಕರಗಳು (tools) ಈ ಎರಡು ಪಾತ್‌ಗಳನ್ನು (paths) ಹುಡುಕುತ್ತವೆ:

  • /.well-known/oauth-authorization-server
  • /.well-known/oauth-protected-resource

ಇವು ಅಥರೈಸೇಶನ್ (authorization) ಮತ್ತು ಟೋಕನ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು (token endpoints) ಎಲ್ಲಿ ಹುಡುಕಬೇಕೆಂದು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ತಿಳಿಸುತ್ತವೆ.

ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಆ ನಿರ್ದಿಷ್ಟ ಪಾತ್‌ಗಳನ್ನು ಹುಡುಕುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಅವು /.well-known/openid-configuration ಅನ್ನು ಹುಡುಕುತ್ತವೆ.

ಇದು OpenID Connect ಪಾತ್ ಆಗಿದೆ. ಇದು ವಿಭಿನ್ನ ಸ್ಪೆಕ್ (spec) ಆಗಿದೆ, ಆದರೆ ಇದು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿರುತ್ತದೆ. ನನ್ನ ಪ್ಯಾಕೇಜ್ OAuth ಸ್ಪೆಕ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಹೊರತು OIDC ಸ್ಪೆಕ್ ಅನ್ನು ಅಲ್ಲದ ಕಾರಣ, ಇದು ಈ ಪಾತ್ ಅನ್ನು ರಿಜಿಸ್ಟರ್ ಮಾಡಿರಲಿಲ್ಲ.

ಕ್ಲೈಂಟ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಬಾಗಿಲನ್ನು ತಟ್ಟುತ್ತದೆ. ಅದು 404 ಎರರ್ (error) ಪಡೆಯುತ್ತದೆ ಮತ್ತು ನಿಂತುಹೋಗುತ್ತದೆ.

ನನ್ನ ಮುಂದೆ ಎರಡು ಆಯ್ಕೆಗಳಿದ್ದವು:

  1. Nginx ನಲ್ಲಿ ರಿವರ್ಸ್-ಪ್ರೊಕ್ಸಿ ರಿಡೈರೆಕ್ಟ್ (reverse-proxy redirect) ಬಳಸುವುದು. ಇದು ಒಂದು ಸೋಮಾರಿ ಪರಿಹಾರ (lazy fix). ಇದು ನಿಮ್ಮ ಲಾಜಿಕ್ ಅನ್ನು ಕೋಡ್‌ನಿಂದ ಹೊರತೆಗೆದು ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್‌ಗೆ (infrastructure) ವರ್ಗಾಯಿಸುತ್ತದೆ. ಇದನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಕಷ್ಟ ಮತ್ತು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ಇದು ಸುಲಭವಾಗಿ ದೋಷಕ್ಕೆ ಒಳಗಾಗಬಹುದು.

  2. ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಳಗಡೆಯೇ ಸರಿಪಡಿಸುವುದು. ಇದು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಆ ಪ್ರೋಬ್‌ಗೆ (probe) ಉತ್ತರಿಸುವಂತೆ ಮಾಡಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ನಾನು OpenID ಪಾತ್ ಅನ್ನು OAuth ಅಥರೈಸೇಶನ್ ಪಾತ್‌ಗೆ ರಿಡೈರೆಕ್ಟ್ ಮಾಡುವ ಒಂದು ಏಲಿಯಾಸ್ (alias) ಅನ್ನು ರಚಿಸಿದೆ.

ನಾನು 308 Permanent Redirect ಅನ್ನು ಬಳಸಿದೆ.

302 ರಿಡೈರೆಕ್ಟ್ ಒಂದು POST ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು GET ರಿಕ್ವೆಸ್ಟ್ ಆಗಿ ಬದಲಾಯಿಸಬಹುದು. ಆದರೆ 308 ರಿಡೈರೆಕ್ಟ್ ಕಟ್ಟುನಿಟ್ಟಾದದ್ದು. ಇದು ಕ್ಲೈಂಟ್‌ಗೆ ಹೊಸ URL ಗೆ ಹೋಗಲು ಮತ್ತು ಅದೇ ಮೆಥಡ್ ಮತ್ತು ಬಾಡಿಯನ್ನು (body) ಉಳಿಸಿಕೊಳ್ಳಲು ತಿಳಿಸುತ್ತದೆ. ಶಾಶ್ವತ ಬದಲಾವಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ಸರಿಯಾದ ಮಾರ್ಗವಾಗಿದೆ.

ನಾನು ಇದನ್ನು ಒಂದು ಕಾನ್ಫಿಗರೇಶನ್ ಫ್ಲಾಗ್ (configuration flag) ಹಿಂದೆ ಇರಿಸಿದ್ದೇನೆ. ಇದು ಬಳಕೆದಾರರು ತಮ್ಮದೇ ಆದ OIDC discovery ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ ಇದನ್ನು ಆಫ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಕೋಡ್‌ನಲ್ಲಿ ಇದನ್ನು ಮಾಡುವ ಮೂಲಕ, ನಾನು ಪರೀಕ್ಷೆಗಳನ್ನು (tests) ಬರೆಯಬಹುದು:

  • ಒಂದು ಪರೀಕ್ಷೆಯು ರಿಡೈರೆಕ್ಟ್ ಸರಿಯಾಗಿ ನಡೆಯುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
  • ಇನ್ನೊಂದು ಪರೀಕ್ಷೆಯು ಮೆಟಾಡೇಟಾ (metadata) ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ರಿಡೈರೆಕ್ಟ್ ಅನ್ನು ಫಾಲೋ ಮಾಡುತ್ತದೆ.

ಇದರಿಂದ ಮೆಟಾಡೇಟಾ ರಚನೆಯು ಬದಲಾದರೆ, ನನ್ನ ಪರೀಕ್ಷೆಗಳು ತಕ್ಷಣವೇ ವಿಫಲವಾಗುತ್ತವೆ. ಬಳಕೆದಾರರು ಕನೆಕ್ಟ್ ಆಗಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಬದಲು, ನಾನು ನನ್ನ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲೇ (pipeline) ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚಬಲ್ಲೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸ್ಪೆಕ್‌ಗಳು (specs) ಹೆಚ್ಚಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಎರಡು ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ಗಳು ಒಂದೇ ರೀತಿಯ ಗುರಿಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ, ಕ್ಲೈಂಟ್‌ಗಳು ವಿಭಿನ್ನ ಪಾತ್‌ಗಳನ್ನು ಆರಿಸಿಕೊಳ್ಳಬಹುದು. ಒಬ್ಬ ಸರ್ವರ್ ಡೆವಲಪರ್ ಆಗಿ, ನೀವು ಎರಡೂ ಬಾಗಿಲುಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು.

ಅವುಗಳನ್ನು ಒಂದೇ ಕೋಣೆಗೆ ತೋರಿಸಿ, ಸರಿಯಾದ ರಿಡೈರೆಕ್ಟ್ ಕೋಡ್ ಬಳಸಿ ಮತ್ತು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಅದನ್ನು ದೃಢೀಕರಿಸಿ.

Source: https://dev.to/nasrulhazim/the-well-knownopenid-configuration-alias-that-makes-mcp-connectors-just-work-27j2