ಪ್ರಾಕ್ಸಿ ಮೂಲಕ 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 ನ ಅಧಿಕೃತತೆ-ಕೋಡ್ ಹರಿವಿಗೆ ಕಾಲ್‌ಬ್ಯಾಕ್ ನಂತರ ತನ್ನದೇ ಟೋಕನ್ ವಿನಿಮಯವಿದೆ. ನಿಖರ ಕ್ರಮವು ತಂತ್ರವನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದರೆ ಬ್ರೌಸರ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಪ್ರತ್ಯೇಕ ಆರಂಭದ ಬಿಂದುಗಳಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ.

ಕ್ಲೈಂಟ್‌ನ ಸಂರಚನೆಯನ್ನು ಹುಡುಕಿ

ತಂತ್ರವನ್ನು ಅನುಸರಿಸಿ ಅದರ ಟೋಕನ್ ಮತ್ತು ಪೂರೈಕೆದಾರರ API ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ HTTP ಕ್ಲೈಂಟ್‌ವರೆಗೆ ಹೋಗಿ. ಆ ಕ್ಲೈಂಟ್‌ನ ದಾಖಲಿತ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ. ಕೆಲವು ತಂತ್ರಗಳು ಕ್ಲೈಂಟ್ ಆಯ್ಕೆಗಳನ್ನು OAuth ಗ್ರಂಥಾಲಯಕ್ಕೆ ರವಾನಿಸುತ್ತವೆ; ಇತರವು ಅದರ ಕೆಳಗೆ HTTP ಸಂಪರ್ಕವನ್ನು ಸಂರಚಿಸುತ್ತವೆ. ಒಂದು ತಂತ್ರ ಸ್ವೀಕರಿಸುವ ಆಯ್ಕೆ ತಾನಾಗಿಯೇ ಹಂಚಿದ OmniAuth ಆಯ್ಕೆಯಾಗುವುದಿಲ್ಲ.

ಪೂರೈಕೆದಾರರ ಅಧಿಕೃತತೆ, ಟೋಕನ್ ಮತ್ತು ಕಾಲ್‌ಬ್ಯಾಕ್ URL ಗಳು ಅವರ ನಿಜವಾದ ಸೇವೆಗಳನ್ನು ವಿವರಿಸಲಿ. ಹೊರಹೋಗುವ ಪ್ರಾಕ್ಸಿ ಪೂರೈಕೆದಾರರನ್ನು ತಲುಪುವ ಸಾಗಣೆ ಸೆಟ್ಟಿಂಗ್, ಅದು ಕಾಲ್‌ಬ್ಯಾಕ್ ವಿಳಾಸದ ಬದಲಿ ಅಲ್ಲ ಮತ್ತು OAuth ವಿನಂತಿ ನಿಯತಾಂಕಗಳಿಗೆ ಸೇರಿಸುವ ಕ್ಷೇತ್ರವಲ್ಲ.

ಲಾಗಿನ್ ಜಾಡಿಸುವಾಗ ಕೊನೆಯ ಪೂರ್ಣಗೊಂಡ ಹಂತವನ್ನು ಗುರುತಿಸಿ. ತೋರಿಸಿದ ಪೂರೈಕೆದಾರರ ಲಾಗಿನ್ ಪುಟ ಬ್ರೌಸರ್ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. Rails ಸ್ವೀಕರಿಸಿದ ಕಾಲ್‌ಬ್ಯಾಕ್ ಬ್ರೌಸರ್ ಮರಳಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ನಂತರದ ಟೋಕನ್ ವಿನಂತಿಯೇ Rails ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬರುವ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕ, ಸವಾಲು ಅಥವಾ ಪೂರೈಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಸ್ಥಳ.