ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳಲ್ಲಿ ಡೊಮೇನ್-ಅರ್ಹ ಬಳಕೆದಾರ ಹೆಸರುಗಳು
ಅಸ್ಪಷ್ಟ ಖಾತೆ ಹೆಸರನ್ನು ಪ್ರತ್ಯೇಕ ಡೊಮೇನ್ ಕ್ಷೇತ್ರಗಳಿರುವ API ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ, ಮತ್ತು ಕೇವಲ URL ವಾಕ್ಯರಚನೆ ಪೂರೈಸಲು ಖಾತೆ ಗುರುತನ್ನು ಬದಲಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
ಒಂದು ಉತ್ತರ DOMAIN\ ತೆಗೆದುಹಾಕಿ ಎನ್ನುತ್ತದೆ. ಇನ್ನೊಂದು ಅದನ್ನು ಸೇರಿಸಿ ಎನ್ನುತ್ತದೆ. ಎರಡೂ ಬದಲಾವಣೆಗಳು ನಿಮ್ಮ ಪ್ರಾಕ್ಸಿಗೆ ತಪ್ಪಾಗಿರಬಹುದು.
ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ: ಸೇವೆ ಯಾವ ಗುರುತನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಆಯ್ದ API ಆ ಗುರುತನ್ನು ಹೇಗೆ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
| ಇಂಟರ್ಫೇಸ್ | ಏನನ್ನು ನಿರ್ಧರಿಸಬೇಕು |
|---|---|
| ಒಂದೇ ಖಾತೆ-ಹೆಸರು ಕ್ಷೇತ್ರ | ನಿರ್ವಾಹಕರು ಸ್ವೀಕರಿಸುವ ನಿಖರ ಖಾತೆ ವಾಕ್ಯರಚನೆ |
| ಡೊಮೇನ್ ಕ್ಷೇತ್ರವಿರುವ ರುಜುವಾತು API | ಡೊಮೇನ್ ಮತ್ತು ಬಳಕೆದಾರ ಹೆಸರನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೀಡಬೇಕೇ |
| URI ಒಳಗಿನ ರುಜುವಾತು ಘಟಕಗಳು | ಉದ್ದೇಶಿತ ಮೌಲ್ಯಗಳನ್ನು ಆ ಪಾತ್ರೆಗೆ ಹೇಗೆ ಎನ್‌ಕೋಡ್ ಮಾಡಬೇಕು |
ಉದಾಹರಣೆಗೆ, .NET ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರ ಹೆಸರು, ಗುಪ್ತಪದ ಮತ್ತು ಡೊಮೇನ್ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳಿರುವ NetworkCredential ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್ ಒದಗಿಸುತ್ತದೆ. ಡೊಮೇನ್ ಅನ್ನು ಭೇದವಿಲ್ಲದೆ ಎರಡು ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಇಡುವುದು ಏಕೀಕೃತ ದೃಢೀಕರಣವನ್ನು ಸಂರಚಿಸುವ ಸಾಗಣೀಯ ದಾರಿಯಲ್ಲ.
Basic ದೃಢೀಕರಣ ಇನ್ನೊಂದು ಸಂದರ್ಭ: ಸರ್ವರ್ ಒದಗಿಸಿದ ಖಾತೆ ಪಠ್ಯವನ್ನು ತನ್ನದೇ ನೀತಿಯಡಿ ಅರ್ಥೈಸುತ್ತದೆ. ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವುದು ಡೊಮೇನ್ ಪೂರ್ವಪ್ರತ್ಯಯ ಸೂಚಿತವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಡೊಮೇನ್-ಅರ್ಹ ಹೆಸರು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬೇರೆ ದೃಢೀಕರಣ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ.
URL ಎಸ್ಕೇಪಿಂಗ್ ಉದ್ದೇಶಿತ ಖಾತೆಯನ್ನು ಸಂರಕ್ಷಿಸಬೇಕು, ಬದಲಿಸುವ ಬದಲು. ಮೂಲ ಭಾಷೆಯ ಸ್ಟ್ರಿಂಗ್‌ನಲ್ಲಿನ ಬ್ಯಾಕ್‌ಸ್ಲ್ಯಾಶ್, ಖಾತೆ ಹೆಸರಿನಲ್ಲಿನ ಬ್ಯಾಕ್‌ಸ್ಲ್ಯಾಶ್ ಮತ್ತು URI ಒಳಗೆ ಅದರ ಶೇಕಡಾ-ಎನ್‌ಕೋಡೆಡ್ ನಿರೂಪಣೆ ಪ್ರತ್ಯೇಕ ಪದರಗಳು.
ಸ್ವೀಕೃತ ಗುರುತಿನ ರೂಪ ಮತ್ತು ಸ್ಕೀಮ್ ಅನ್ನು ನಿರ್ವಾಹಕರಿಂದ ಪಡೆಯಿರಿ, ನಂತರ ಸಂಬಂಧಿತ ರುಜುವಾತು ಇಂಟರ್ಫೇಸ್ ಬಳಸಿ. ಸಣ್ಣ ಹೆಸರು, ಡೊಮೇನ್ ಹೆಸರು ಮತ್ತು ಇಮೇಲ್‌ನಂತಹ ಹೆಸರಿನ ನಡುವೆ ಯದ್ವಾತದ್ವಾ ಬದಲಾಯಿಸುವುದು ಮೂಲ 407 ಬಗ್ಗೆ ದುರ್ಬಲ ಸಾಕ್ಷ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.