VPN ಸರ್ವರ್ ಬದಲಿಸಿದರೆ ನೀವು ಅಂಗಡಿಯಿಂದ ಲಾಗ್ ಔಟ್ ಆಗುತ್ತೀರಾ?
ಹೊಸ ನಿರ್ಗಮನ ವಿಳಾಸ ಕುಕಿ ಜಾರ್ ಅನ್ನು ಖಾಲಿ ಮಾಡುವುದಿಲ್ಲ. ಮೊದಲು ನೀವು ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗ, ಲಾಗ್-ಇನ್ ಸೆಷನ್ ಅಥವಾ ಸಂಗ್ರಹಿಸಿದ ಸೈಟ್ ಡೇಟಾವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಾ ಎಂದು ನಿರ್ಧರಿಸಿ.
ಇನ್ನೊಂದು ಟ್ಯಾಬ್ನಲ್ಲಿ ಅಂಗಡಿ ತೆರೆದಿರುವಾಗ VPN ನಿರ್ಗಮನವನ್ನು ಬದಲಿಸಿ, ಬುಟ್ಟಿ ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನೂ ಇರುತ್ತದೆ. ಇದು VPN ವೈಫಲ್ಯವಲ್ಲ; ಬ್ರೌಸರ್ ತನಗೆ ಹೇಳಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತಿದೆ. ಕುಕಿಯನ್ನು ಬ್ರೌಸರ್ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಹೊಸ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗ ಬ್ರೌಸರ್ ಸಂಗ್ರಹಿಸುವುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. «ಸೈಟ್ ಇನ್ನೂ ನನ್ನನ್ನು ತಿಳಿದಿದೆ» ಎಂಬ ಮಾತಿನ ಹಿಂದೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿವೆ, ಮತ್ತು ನೀವು ಯಾವುದನ್ನು ಕೇಳುತ್ತಿದ್ದೀರಿ ಎಂಬುದರ ಮೇಲೆ ಉತ್ತರ ಅವಲಂಬಿತವಾಗಿದೆ.
ಮೂರು ಪ್ರಶ್ನೆಗಳು, ಒಂದು ಲಕ್ಷಣ
ಮೊದಲನೆಯದು: ಸೈಟ್ ಸಂಗ್ರಹಿಸಿದ ಕುಕಿಯನ್ನು ಗುರುತಿಸುತ್ತದೆಯೇ? ಎರಡನೆಯದು: ಯಾವುದೇ ಒಂದು ಕುಕಿಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಉಳಿಯುವ ಲಾಗ್-ಇನ್ ಆದ ಖಾತೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆಯೇ? ಮೂರನೆಯದು: ಸಂಗ್ರಹಿಸಿದ ಸ್ಥಿತಿಯ ಬದಲು ಬ್ರೌಸರ್ ಅಥವಾ ಸಾಧನದ ಬಗ್ಗೆ ಏನನ್ನಾದರೂ ಗುರುತಿಸುತ್ತದೆಯೇ? ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದರದೇ ಪರೀಕ್ಷೆ ಮತ್ತು ಅದರದೇ ಪರಿಹಾರವಿದೆ.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
ಹೆಚ್ಚಿನ ಗೊಂದಲ ಮೊದಲನೆಯದನ್ನು ಬದಲಿಸಿ ಎರಡನೆಯದು ಅನುಸರಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವುದರಿಂದ ಬರುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ವಿಳಾಸ ಮತ್ತು ಬ್ರೌಸರ್ ಸ್ಟೋರ್ ಎರಡು ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳು, ಅವನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಅದೇ ಪುಟ ಬಳಸುತ್ತದೆ.
ಕುಕಿ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ
RFC 6265ರಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ HTTP ಸ್ಥಿತಿ ನಿರ್ವಹಣೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸರಳವಾಗಿದೆ: ಸರ್ವರ್ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಹೆಸರು ಮತ್ತು ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವ್ಯಾಪ್ತಿಗೆ ಹೊಂದುವ ವಿನಂತಿಗಳಿಗೆ ಬ್ರೌಸರ್ ಅವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಮೌಲ್ಯವು ಸೆಷನ್ ಗುರುತಿಸುವಿಕೆ, ಆದ್ಯತೆ ಅಥವಾ ಸರ್ವರ್ ಬುಟ್ಟಿ ದಾಖಲೆಗೆ ನಕ್ಷೆ ಮಾಡುವ ಅಪಾರದರ್ಶಕ ಟೋಕನ್ ಆಗಿರಬಹುದು. ಈ ಕಾರ್ಯವಿಧಾನದಲ್ಲಿ ಎಲ್ಲಿಯೂ ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ಹೇಳಿಲ್ಲ.
ಈ ವಿನ್ಯಾಸವೇ ಸಾಮಾನ್ಯ ಲಾಗಿನ್ಗಳು ಮತ್ತು ಬುಟ್ಟಿಗಳು ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳುವ ಕಾರಣ, ಮತ್ತು ಟ್ರ್ಯಾಕರ್ಗಳಿಗೂ ಅವು ಅದನ್ನು ಉಳಿದುಕೊಳ್ಳುವ ಕಾರಣ. ಅದೇ ಕಾರ್ಯವಿಧಾನ ಎರಡೂ ಉದ್ದೇಶಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಭೇದ ಮಾಡುವುದಿಲ್ಲ. ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ನ ವಿಳಾಸಕ್ಕೆ ಯಾವುದೇ ಕ್ಷೇತ್ರವಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊಸ ನಿರ್ಗಮನಕ್ಕೆ ಅಸಿಂಧು ಮಾಡಲು ಏನೂ ಇಲ್ಲ. ಕುಕಿಯನ್ನು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ್ಕೆ ಬಿಗಿಯಲು ಬಯಸುವ ಸೈಟ್ ಆ ತರ್ಕವನ್ನು ತಾನೇ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ.
ಸೈಟ್ ಕುಕಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿದಾಗ, ಸರ್ವರ್ ಆ ಮೌಲ್ಯ ತೋರಿಸುವ ದಾಖಲೆಯನ್ನು ಹುಡುಕುತ್ತದೆ. ವಿನಂತಿ ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುವುದು ಆ ಹುಡುಕಾಟವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಖರೀದಿ ಬುಟ್ಟಿಯ ವೀಕ್ಷಣೆಯ ಸಂಪೂರ್ಣ ವಿವರಣೆ ಅದೇ.
ನಿಮ್ಮ ಪರೀಕ್ಷೆ ಏನನ್ನು ಅಳೆಯುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ನೀವು ಪ್ರಾರಂಭಿಸುವ ಸ್ಥಿತಿಯನ್ನು ಬರೆಯಿರಿ: ಯಾವ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್, ಯಾವ ಖಾತೆ, ಯಾವ ಸೈಟ್ ಡೇಟಾ, ಯಾವ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗ. ನಂತರ ಅವುಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಒಂದನ್ನು ಬದಲಿಸಿ ಗಮನಿಸಿ. ನಿರ್ಗಮನ ವಿಳಾಸ ಮತ್ತು ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಬದಲಿಸುವ ಪರೀಕ್ಷೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದರ ಬಗ್ಗೆಯೂ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartಎರಡೂ ಆದೇಶಗಳು ಒಂದೇ ಕುಕಿ ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಬಳಸುತ್ತವೆ, ಮತ್ತು ಎರಡನೆಯದು ಹೋಸ್ಟ್ ಅನುಮತಿಸುವಲ್ಲಿ ಬೇರೆ ಸ್ಥಳೀಯ ಮೂಲ ವಿಳಾಸವನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬುಟ್ಟಿಯ ಪ್ರತಿಕ್ರಿಯೆ ಒಂದೇ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಎಂದೂ ಬೇರೆ ಕ್ಲೈಂಟ್ ಗುರುತನ್ನು ನೋಡಿಲ್ಲ, ಬೇರೆ ಮಾರ್ಗವನ್ನಷ್ಟೇ ನೋಡಿತು. ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಒಂದೇ ಜೋಡಿ ವಿನಂತಿಗಳಲ್ಲಿ ಇದೇ ಕಾರ್ಯವಿಧಾನ.
ಸಂಗ್ರಹಿಸಿದ ಸ್ಥಿತಿ ಇಲ್ಲದೆ ಸೈಟ್ ನಿಮ್ಮನ್ನು ಗುರುತಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡುವುದು ಗುರಿಯಾಗಿದ್ದರೆ, ಆ ಸೈಟ್ನ ಡೇಟಾವನ್ನು ಅಳಿಸಿ ಪುನರಾವರ್ತಿಸಿ. ಅದು ಇನ್ನೂ ಗುರುತಿಸಿದರೆ, ಮುಂದಿನ ಸಂಶಯಿತರು ಕುಕಿ ಅಲ್ಲ, ಲಾಗ್-ಇನ್ ಆದ ಖಾತೆ, ನೀವು ಅನುಸರಿಸಿದ ಕೊಂಡಿ ಅಥವಾ ಬ್ರೌಸರ್ ಗುಣಲಕ್ಷಣಗಳು.
ಸರಿಯಾದ ಸ್ಥಿತಿಯನ್ನು ಅಳಿಸಿ, ನೆಟ್ವರ್ಕ್ ಅಲ್ಲ
ಒಂದು ಸೈಟ್ನ ಸಂಗ್ರಹಣೆಯನ್ನು ತೆಗೆಯುವುದು ಬ್ರೌಸರ್ನ ಸ್ವಂತ ನಿಯಂತ್ರಣಗಳಿಗೆ ಸೇರಿದ್ದು, ಮತ್ತು ಅದು ಹಲವುವೇಳೆ ಅಡ್ಡಪರಿಣಾಮವಾಗಿ ನಿಮ್ಮನ್ನು ಲಾಗ್ ಔಟ್ ಮಾಡುತ್ತದೆ ಅಥವಾ ಆದ್ಯತೆಗಳನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ. ಅದು ಖಾತೆಯನ್ನು ಅಥವಾ ಸೇವೆ ಈಗಾಗಲೇ ಇಟ್ಟುಕೊಂಡಿರುವ ದಾಖಲೆಗಳನ್ನು ಅಳಿಸುವುದಿಲ್ಲ; ಅವಕ್ಕೆ ಸೇವೆಯ ಸ್ವಂತ ಪ್ರಕ್ರಿಯೆ ಬೇಕು.
ಅಂತರ್-ಸೈಟ್ ನಿರ್ಬಂಧಗಳು ಸಮಸ್ಯೆಯ ಇನ್ನೊಂದು ಭಾಗವನ್ನು ನಿಭಾಯಿಸುತ್ತವೆ. ಬ್ರೌಸರ್ಗಳು ಎಂಬೆಡ್ ಮಾಡಿದ ಸೇವೆಗಳು ಸೈಟ್ಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳುವ ಸಂಗ್ರಹಣೆಯನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು ಅಥವಾ ವಿಭಜಿಸಬಹುದು, ಆದರೆ ಮೊದಲ-ಪಕ್ಷದ ಲಾಗಿನ್ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ಲಾಗಿನ್ ಅಂತರ್-ಸೈಟ್ ಟ್ರ್ಯಾಕಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಖಾಸಗಿ ಕಿಟಕಿಗಳು ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಸಣ್ಣ ವ್ಯಾಪ್ತಿಯ ಇನ್ನೊಂದು ಸಾಧನ. ಸೈಟ್ಗಳು ಸೆಷನ್ ಸಮಯದಲ್ಲಿ ಇನ್ನೂ ಕುಕಿ ಹೊಂದಿಸಬಹುದು, ಮತ್ತು ಲಾಗಿನ್ ಇನ್ನೂ ಖಾತೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ. ತಾತ್ಕಾಲಿಕ ಸ್ಥಿತಿಯನ್ನು ಬಿಸಾಡುವುದು ಖಾಸಗಿ ಸೆಷನ್ ಮುಗಿಸುವುದೇ, ಅಂದರೆ ಒಂದು ಟ್ಯಾಬ್ ಅಲ್ಲ, ಪ್ರತಿ ಖಾಸಗಿ ಕಿಟಕಿಯನ್ನು ಮುಚ್ಚಬೇಕು.
ಕೊನೆಯದಾಗಿ, ಫಿಂಗರ್ಪ್ರಿಂಟಿಂಗ್ ಮೂಲಕ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಮೊದಲ ವಿವರಣೆಯಲ್ಲ, ಸಂಭಾವ್ಯತೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಸಾಧನ ಮತ್ತು ಬ್ರೌಸರ್ ಗುಣಲಕ್ಷಣಗಳು ಯಾವುದೇ ಸಂಗ್ರಹಿಸಿದ ಕುಕಿ ಇಲ್ಲದೆ ಭೇಟಿಗಳನ್ನು ಜೋಡಿಸಬಹುದು, ಮತ್ತು ಸಂಗ್ರಹಣೆ ಅಳಿಸುವುದು ಅವನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ. ಮೊದಲು ಸರಳ ಕಾರಣಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ತನಿಖೆಯನ್ನು ವಿಸ್ತರಿಸಿ, ಮತ್ತು ಮುಂದಿನ ಹೋಲಿಕೆ ಅರ್ಥಪೂರ್ಣವಾಗಲು ಯಾವ ಸ್ಥಿತಿ ಬದಲಿಸಿದಿರಿ ಎಂದು ಟಿಪ್ಪಣಿ ಮಾಡಿ.