ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಇದು ಕೆಲಸದ ಸೆಷನ್ನ ಒಂದು ಗಂಟೆಯ ನಂತರ ಯದೃಚ್ಛಿಕ ಸಂಪರ್ಕ ಕಡಿತದಂತೆ ಕಾಣುತ್ತದೆ. ಟ್ರೇ ಐಕಾನ್ ಮಾಯವಾಗುತ್ತದೆ, ಸುರಂಗ ಮತ್ತೆ ನಿರ್ಮಾಣವಾಗುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ ನೆಟ್ವರ್ಕ್ ದೋಷದ ಬದಲು ದೃಢೀಕರಣ ವೈಫಲ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ ಸೆಷನ್ ಮರು-ಸಮಾಲೋಚನೆ ಮಾಡಿತು ಮತ್ತು ಎರಡನೇ ಹ್ಯಾಂಡ್ಶೇಕ್ಗೆ ಕ್ಲೈಂಟ್ ಬಳಿ ಇನ್ನು ಮಾನ್ಯ ಪ್ರತಿ ಇಲ್ಲದ ರುಜುವಾತುಗಳು ಬೇಕಾದವು. ಲಾಗಿನ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದ ಒಂದು-ಬಾರಿ ಕೋಡ್ ಮತ್ತೆ ಕೆಲಸ ಮಾಡಲಾರದು, ಆದ್ದರಿಂದ ಮರು-ಕೀಲಿ ನಿಖರವಾಗಿ ವಿನ್ಯಾಸದಂತೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಪರಿಹಾರ ಎರಡನೇ ಹ್ಯಾಂಡ್ಶೇಕ್ ಏನನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಬೇಕು ಎಂಬ ನಿರ್ಣಯ, ಹೆಚ್ಚು ಉದ್ದದ ಮರುಪ್ರಯತ್ನ ಟೈಮರ್ ಅಲ್ಲ.

ಕ್ಲೈಂಟ್ ದೃಷ್ಟಿಕೋನದಿಂದ ವಿನಿಮಯವನ್ನು ನಡೆಯಿರಿ

ಲಾಗಿನ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಬಳಕೆದಾರ ಹೆಸರು, ಗುಪ್ತಪದ ಮತ್ತು ಟೋಕನ್ ಸಾಧನದ ಕೋಡ್ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಆ ಸಂಯೋಜನೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನಂತರ ಸೆಷನ್ ಮರು-ಸಮಾಲೋಚನೆ ಪ್ರಚೋದಕ ಸಕ್ರಿಯವಾಗುವವರೆಗೆ ನಡೆಯುತ್ತದೆ, ಅದು ಇರುವ ಸುರಂಗದ ಒಳಗೆ ಹೊಸ TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಮತ್ತೆ ದೃಢೀಕರಣ ಕೇಳುತ್ತದೆ. ಸರ್ವರ್ನ ದೃಢೀಕರಣ ಮಾರ್ಗ ಗುಪ್ತಪದ ಮತ್ತು ಪ್ರಸ್ತುತ ಒಂದು-ಬಾರಿ ಕೋಡ್ ನಿರೀಕ್ಷಿಸಿದರೆ, ಬಳಕೆದಾರ ಅಲ್ಲಿದ್ದು ಟೈಪ್ ಮಾಡದ ಹೊರತು ಕ್ಲೈಂಟ್ಗೆ ನೀಡಲು ಹೊಸ ಕೋಡ್ ಇಲ್ಲ.

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

auth-gen-token ಎರಡನೇ ಪ್ರಶ್ನೆಗೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ

ಆಯ್ಕೆ auth-gen-token ಯಶಸ್ವಿ ಲಾಗಿನ್ ನಂತರ ಸರ್ವರ್ ಟೋಕನ್ ನೀಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರದ ಮರು-ಸಮಾಲೋಚನೆಗಳು ಗುಪ್ತಪದ ಮತ್ತು ಕೋಡ್ ಪುನರಾವರ್ತಿಸುವ ಬದಲು ಆ ಟೋಕನ್ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತವೆ. ಕೈಪಿಡಿ ಅದರ ಜೀವಿತಾವಧಿ ಮತ್ತು ನವೀಕರಣ ವರ್ತನೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಟೋಕನ್ ತನ್ನದೇ ಅವಧಿ ಹೊಂದಿರುವ ರುಜುವಾತಾಗಿ ಪರಿಗಣಿಸಬೇಕು. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ಸರ್ವರ್ ಬಾಹ್ಯ ಗುಪ್ತಪದ ದೃಢೀಕರಣಕಾರನನ್ನು ಮತ್ತೆ ಕರೆಯುವ ಬದಲು ಟೋಕನ್ ತಾನೇ ಪರಿಶೀಲಿಸುತ್ತದೆ.

ಬಾಹ್ಯ ದೃಢೀಕರಣ ಸಂಯೋಜನೆಯೊಂದಿಗೆ ಆ ವಿಭಜನೆ ಬದಲಾಗುತ್ತದೆ. ಪ್ಲಗಿನ್ ಟೋಕನ್ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ತನ್ನದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕು, ಏಕೆಂದರೆ ಸೆಷನ್ ಮುಂದುವರಿಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಏಕೈಕ ಘಟಕ ಇನ್ನು ಸರ್ವರ್ ಅಲ್ಲ. ಟೋಕನ್ ಅನ್ನು ಇನ್ನೊಂದು ಸಂಖ್ಯಾತ್ಮಕ ಒಂದು-ಬಾರಿ ಕೋಡ್ ಎಂದು ಪರಿಗಣಿಸುವುದು ಈ ವೈಶಿಷ್ಟ್ಯದ ಅನುಷ್ಠಾನವಲ್ಲ.

ಖಾತೆಯ ಸ್ಥಿತಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ಖಾತೆಯ ಪ್ರವೇಶಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುವ ಟೋಕನ್ ನೀತಿಯಲ್ಲಿನ ರಂಧ್ರ. ನಿಷ್ಕ್ರಿಯ ಖಾತೆ, ತೆಗೆದುಹಾಕಿದ ಗುಂಪು ಸದಸ್ಯತ್ವ ಅಥವಾ ರದ್ದಾದ ಸಾಧನವು ಟೋಕನ್ ಇನ್ನೂ ಮಾನ್ಯವಾಗಿರುವಾಗ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಟೋಕನ್ನ ಸಣ್ಣ ಜೀವಿತಾವಧಿ ಕಿಟಕಿಯನ್ನು ಸಣ್ಣದಾಗಿಸುತ್ತದೆ; ಸ್ಪಷ್ಟ ರದ್ದತಿ ಮಾರ್ಗ ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿಸುತ್ತದೆ. ಆಯ್ಕೆ ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು ಉತ್ತರ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಪ್ರತಿ ಮರು-ಸಮಾಲೋಚನೆಯಲ್ಲಿ ಬಾಹ್ಯ ದೃಢೀಕರಣಕಾರನನ್ನು ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ.

ಬಹು-ಸರ್ವರ್ ನಿಯೋಜನೆಯಲ್ಲಿ ಟೋಕನ್ ಸಹಿ ರಹಸ್ಯ ಹಂಚಿಕೆಯಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ತನ್ನ ಟೋಕನ್ ಪರಿಶೀಲಿಸಲಾಗದ ನೋಡ್ಗೆ ಕಳುಹಿಸಲ್ಪಡಬಹುದು.

ಲಾಗಿನ್ ಮಾತ್ರವಲ್ಲ, ಅವಧಿ ಮುಗಿಯುವಿಕೆ ಮತ್ತು ಮರುಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಪರೀಕ್ಷಾ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಮರು-ಸಮಾಲೋಚನೆ ಮಧ್ಯಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಿ, ಎರಡನೇ ಹ್ಯಾಂಡ್ಶೇಕ್ ನೀವು ನೋಡುತ್ತಿರುವಾಗಲೇ ನಡೆಯಲಿ, ನಂತರ ಎರಡೂ ಲಾಗ್ಗಳನ್ನು ಅನುಸರಿಸಿ. ಟೋಕನ್ ಲಾಗಿನ್ನಲ್ಲಿ ನೀಡಲ್ಪಟ್ಟಿದೆಯೇ, ಮರು-ಕೀಲಿಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲ್ಪಟ್ಟಿದೆಯೇ, ಮತ್ತು ಸಂರಚಿತ ಜೀವಿತಾವಧಿಗೆ ಅನುಗುಣವಾಗಿ ನವೀಕರಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಅಥವಾ ಮರುನೀಡಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಟೋಕನ್ ಅವಧಿ ಮುಗಿಯುವಿಕೆ ಮತ್ತು ಪೂರ್ಣ ಮರುಸಂಪರ್ಕವನ್ನು ಒತ್ತಾಯಿಸಿ, ಏಕೆಂದರೆ ಸ್ವಚ್ಛವಾಗಿ ಮರುಸಂಪರ್ಕಗೊಳ್ಳುವ ಕ್ಲೈಂಟ್ ಕೂಡ ಮರು-ಕೀಲಿ ಮಾರ್ಗದಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.

ಖಾತೆ ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ಕೊನೆಯದಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಆ ಪ್ರಕರಣ ನೀವು ಬರೆದ ನೀತಿ ಜಾರಿಯಾಗುತ್ತದೆಯೇ ಅಥವಾ ಕೇವಲ ದಾಖಲಾಗಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ.

ನವೀಕರಣವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಡಿ

ಎರಡೂ ಪೀರ್ಗಳಲ್ಲಿ ಮರು-ಸಮಾಲೋಚನೆ ಮಧ್ಯಂತರವನ್ನು ಶೂನ್ಯಕ್ಕೆ ಇಳಿಸುವುದು ಲಕ್ಷಣವನ್ನು ಮತ್ತು ಅದರೊಂದಿಗೆ ಕೀಲಿ ತಿರುಗುವಿಕೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಅದು ಯಾರೂ ಪರಿಶೀಲಿಸದ ನೀತಿ ಬದಲಾವಣೆಯ ಹಿಂದೆ ರುಜುವಾತು ಮರುಪ್ಲೇ ಸಮಸ್ಯೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ನವೀಕರಣವನ್ನು ಉಳಿಸಿಕೊಂಡು, ಬಳಕೆದಾರ ಇದ್ದಾರೆಯೇ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಸರ್ವರ್ ನೀಡಿದ ಟೋಕನ್ ಮತ್ತು ಹೊಸ ಸಂವಾದಾತ್ಮಕ ಸವಾಲಿನ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡಿ.

ಉದ್ದವಾದ ಮರುಪ್ರಯತ್ನ ಟೈಮರ್ ಖರ್ಚಾದ ಕೋಡ್ ಅನ್ನು ಮತ್ತೆ ಮಾನ್ಯ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಸಂಪರ್ಕ ಕಡಿತವನ್ನು ವಿಳಂಬಗೊಳಿಸಿ ಲಾಗ್ ಓದಲು ಕಷ್ಟವಾಗಿಸುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು