Chrome onAuthRequired: ರುಜುವಾತುಗಳನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು isProxy ಪರಿಶೀಲಿಸಿ

ಬ್ರೌಸರ್ ವಿಸ್ತರಣೆಯು ಎರಡು ವಿಭಿನ್ನ ಸ್ಥಳಗಳಿಂದ ದೃಢೀಕರಣ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸಬಹುದು: ವಿನಂತಿಯನ್ನು ಸಾಗಿಸುವ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಗಮ್ಯತಾಣದ ವೆಬ್‌ಸೈಟ್. ಅವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒಂದೇ ಖಾತೆಯನ್ನು ಪಡೆಯಬಾರದು.

Chrome ನ webRequest.onAuthRequired ಈವೆಂಟ್‌ನಲ್ಲಿ ಉಪಯುಕ್ತ ವಿಭೇದಕ isProxy ಆಗಿದೆ. ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ ಮಾಯವಾಗಲು ಆ ಪರಿಶೀಲನೆಯನ್ನು ತೆಗೆದುಹಾಕುವ ಕಾಲ್‌ಬ್ಯಾಕ್ ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳನ್ನು ಮೂಲ ಸವಾಲಿಗೆ ಒದಗಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು.

ನೀವು ನಂಬಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರಾಕ್ಸಿಗೆ ಹೊಂದಿಸಿ

isProxy ಪರಿಶೀಲಿಸುವುದು ಆರಂಭ. ನಿರೀಕ್ಷಿತ ಪ್ರಾಕ್ಸಿ ಸವಾಲುಕಾರ ಮತ್ತು ವಿನಂತಿಯ ಸಂದರ್ಭಕ್ಕೆ ನಿರ್ವಹಣೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿ. ಹಲವು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ವಿಸ್ತರಣೆಯು ಪ್ರತಿ ಸವಾಲಿಗೆ ಒಂದೇ ಜಾಗತಿಕ ಪಾಸ್‌ವರ್ಡ್ ಬದಲು ಆ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಸೇರಿದ ಖಾತೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು.

ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಅದರ ಲಾಗಿನ್ ನಿರ್ವಹಿಸುವುದು ಒಂದೇ ಅನುಮತಿ ಅಥವಾ ಒಂದೇ API ಕರೆ ಎಂದು ಭಾವಿಸಬೇಡಿ. Chrome ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ. ಈವೆಂಟ್ ಡೇಟಾ ಮತ್ತು ದೃಢೀಕರಣ ಅನುಮತಿಗಳಿಗೆ ಪ್ರಸ್ತುತ webRequest ಉಲ್ಲೇಖವನ್ನು ಬಳಸಿ. Manifest V3 ಶ್ರೋತೃ ನೋಂದಣಿಯ ಉದಾಹರಣೆ ಕಾಲ್‌ಬ್ಯಾಕ್ ಒಳಗೆ ಸಿಂಕ್ರೊನಸ್ ನೋಂದಣಿ ಮತ್ತು ಖಾತೆ ಆಯ್ಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮ್ಯಾನಿಫೆಸ್ಟ್ ಪೀಳಿಗೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಪ್ರಾಯೋಗಿಕ WebRequest API ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ಉದಾಹರಣೆಗಳು ಹಳೆಯ ವಿಸ್ತರಣಾ ಬಿಡುಗಡೆಗಳಿಂದ ಬಂದವು. ಪ್ರಸ್ತುತ ಅನುಮತಿ ಅಗತ್ಯಗಳು ವಿಸ್ತರಣೆಯ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಪೀಳಿಗೆ ಮತ್ತು ನಿಯೋಜನಾ ಮಾದರಿಯನ್ನು ಅವಲಂಬಿಸಿವೆ. ವಿಶೇಷವಾಗಿ, ದೃಢೀಕರಣ ನಿರ್ವಹಣೆಗೆ ತನ್ನದೇ ಆದ ಬೆಂಬಲಿತ ಅನುಮತಿ ಮಾರ್ಗವಿದೆ; ಹಳೆಯ ತಡೆಯುವ ಶ್ರೋತೃ ಉದಾಹರಣೆ Manifest V3 ವಿಸ್ತರಣೆಯು ಅದನ್ನು ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಚಲಾಯಿಸಬಹುದು ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ.

ಸರಿಯಾದ ಹ್ಯಾಂಡ್ಲರ್ ತಿರಸ್ಕರಿಸಿದ ಅದೇ ರುಜುವಾತುಗಳನ್ನು ಅನಂತವಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಸಹ ತಪ್ಪಿಸಬೇಕು. ಖಾತೆ ನೀಡಿದ ನಂತರ ಬರುವ ಎರಡನೇ ಸವಾಲನ್ನು ಪಾಸ್‌ವರ್ಡ್ ಶಾಶ್ವತವಾಗಿ ಮರುಪ್ಲೇ ಮಾಡುವ ವಿನಂತಿಯಲ್ಲ, ತನಿಖೆಗೆ ಸಾಕ್ಷ್ಯವಾಗಿ ಪರಿಗಣಿಸಿ.

ರುಜುವಾತುಗಳು ವಿಸ್ತರಣೆಯ ಸೂಕ್ತವಾದ ಸಂರಕ್ಷಿತ ನಿರ್ವಹಣಾ ಮಾರ್ಗದಲ್ಲೇ ಇರಬೇಕು. ಅವುಗಳನ್ನು PAC ಫೈಲ್‌ನಲ್ಲಿ ಪ್ರಕಟಿಸಬೇಡಿ ಅಥವಾ ವಿತರಿಸುವ ಮಾದರಿಯಲ್ಲಿ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಬೇಡಿ. ಗುರಿ ಸಂಕುಚಿತ ವ್ಯಾಪ್ತಿಯ ಪ್ರಾಕ್ಸಿ ಲಾಗಿನ್, ಪ್ರತಿ ದೃಢೀಕರಣ ಸವಾಲಿಗೆ ಒಂದೇ ರಹಸ್ಯದಿಂದ ಉತ್ತರಿಸುವ ಬ್ರೌಸರ್-ವ್ಯಾಪಿ ನಿಯಮವಲ್ಲ.