ನಿಮ್ಮ Magento ಮರುನಿರ್ದೇಶನ ಲೂಪ್ ಬಹುಶಃ VPN ಅಲ್ಲ

ನೀವು ಪ್ರವೇಶ ಲಾಗ್ನಲ್ಲಿ 302 ಅನ್ನು ನೋಡುತ್ತೀರಿ, ಸ್ಟೋರ್ಫ್ರಂಟ್ VPN ಮೂಲಕ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ, ಮತ್ತು ತೀರ್ಮಾನವು ತಾನೇ ಬರೆಯುತ್ತದೆ. ಆ ತೀರ್ಮಾನ ಸಾಮಾನ್ಯವಾಗಿ ಆಸಕ್ತಿದಾಯಕ ರೀತಿಯಲ್ಲಿ ತಪ್ಪಾಗಿರುತ್ತದೆ. ಮರುನಿರ್ದೇಶನ ಪ್ರತಿಕ್ರಿಯೆಯು ಬ್ರೌಸರ್ಗೆ ಹೋಗಲು ಹೇಳಿದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಟನೆಲ್, ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸೃಷ್ಟಿಸಿತೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಲಾಗ್ ಸಾಲು ತನಿಖೆಯ ಪ್ರಾರಂಭ, ಅದರ ಕಂಡುಹಿಡಿತವಲ್ಲ.

302 ಎಲ್ಲಿಗೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಏಕೆ ಎಂದಲ್ಲ

ಪ್ರವೇಶ ಲಾಗ್ ನಮೂದು ವಿನಂತಿ, ಸ್ಥಿತಿ ಮತ್ತು ಗಾತ್ರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಮುಖ್ಯವಾದ Location ಹೆಡರ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಒಂದು ಮರುನಿರ್ದೇಶನ ಸಂಪೂರ್ಣ ಸಾಮಾನ್ಯವಾಗಿರಬಹುದು: ಅಂಗೀಕೃತ ಹೋಸ್ಟ್ನಾಮ್, ಕೊನೆಯ ಸ್ಲ್ಯಾಶ್ನ ಸಾಮಾನ್ಯೀಕರಣ, HTTPS ಗೆ ಬದಲಾವಣೆ. ನಿಮಗೆ ಬೇಕಾಗಿರುವುದು ಕ್ರಮ, ಏಕೆಂದರೆ ಒಂದು ಜಿಗಿತ ಮತ್ತು ಲೂಪ್ ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರನ್ನು ಹೊಂದಿರುವ ಬೇರೆ ಬೇರೆ ದೋಷಗಳು. ಸ್ಕೀಮ್ಗಳ ನಡುವೆ ಪುನರಾವರ್ತಿತ ಜಿಗಿತಗಳು URL ಮತ್ತು ಸ್ಕೀಮ್ ನಿರ್ವಹಣೆಯತ್ತ ಸೂಚಿಸುತ್ತವೆ. ಬ್ರೌಸರ್ ಪರಿಹರಿಸಲಾಗದ ಹೆಸರಿನತ್ತ ಜಿಗಿತ ಸಂಪೂರ್ಣ ಬೇರೆಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ VPN ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಟನೆಲ್ ಒಂದು ಮಾರ್ಗ; ಮರುನಿರ್ದೇಶನ ಅಪ್ಲಿಕೇಶನ್ ಬರೆದ ಸೂಚನೆ.

ಸರಪಳಿಯನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ಲಾಗ್ ಸಾಲನ್ನಲ್ಲ

ಬ್ರೌಸರ್ನ ನೆಟ್ವರ್ಕ್ ವೀಕ್ಷಣೆಯನ್ನು ಬಳಸಿ ಮತ್ತು ಪ್ರತಿ ಜಿಗಿತಕ್ಕೂ ನಾಲ್ಕು ಕ್ಷೇತ್ರಗಳನ್ನು ದಾಖಲಿಸಿ: ವಿನಂತಿಸಿದ URL, ಸ್ಥಿತಿ, Location ಹೆಡರ್ ಮತ್ತು ಸಮಯ. ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ಸಂಪರ್ಕ ದೋಷದೊಂದಿಗೆ ಮುಗಿಸಿ, ಏಕೆಂದರೆ ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣ ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದ ಜಿಗಿತ. ಇದನ್ನು ಒಮ್ಮೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗದಲ್ಲಿ ಮತ್ತು ಒಮ್ಮೆ ವಿಫಲವಾಗುವ ಮಾರ್ಗದಲ್ಲಿ, ಅದೇ ಖಾತೆ ಮತ್ತು ಅದೇ ನ್ಯಾವಿಗೇಷನ್ನೊಂದಿಗೆ ಮಾಡಿ. ಎರಡು ಸರಪಳಿಗಳನ್ನು ಹೋಲಿಸುವುದು ಲಾಗ್ನ ಯಾವುದೇ ಒಂದು ಸಾಲಿಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತ.

ಆ ದಾಖಲೆಯನ್ನು ಖಾಸಗಿಯಾಗಿ ಇರಿಸಿ. URL ಗಳು ಸೆಷನ್ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಹೊತ್ತುಕೊಂಡಿರುತ್ತವೆ, ಮತ್ತು ಉಳಿಸಿದ ಬ್ರೌಸರ್ ಆರ್ಕೈವ್ ನೀವು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚನ್ನು ಹೊತ್ತುಕೊಂಡಿರುತ್ತದೆ. ಟಿಕೆಟ್ಗೆ ಏನನ್ನಾದರೂ ಅಂಟಿಸುವ ಮೊದಲು ಪ್ರಶ್ನೆ ಸರಪಳಿಗಳನ್ನು ತೆಗೆದುಹಾಕಿ.

ಅಪ್ಲಿಕೇಶನ್ನ ತನ್ನದೇ URL ಬಗ್ಗೆ ಕಲ್ಪನೆ

Magento ಸಂರಚನೆಯಿಂದ ಸಂಪೂರ್ಣ URL ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಪ್ರತಿ ವೆಬ್ಸೈಟ್ ಅಥವಾ ಸ್ಟೋರ್ ವ್ಯೂ ಪ್ರಕಾರ ವ್ಯಾಪ್ತಿಗೊಳಿಸಲಾಗಿದೆ. bin/magento config:show web/secure/base_url ಅಪ್ಲಿಕೇಶನ್ ನಂಬುವ ಮೌಲ್ಯವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಬ್ರೌಸರ್ ಬಳಸಿದ ಹೆಸರಲ್ಲ, ಬಿಲ್ಡ್ ಅಥವಾ ಸ್ಥಳಾಂತರದಿಂದ ಉಳಿದ ಹೋಸ್ಟ್ನಾಮ್ ಆಗಿರುತ್ತದೆ. ಅಲ್ಲಿ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಹೆಸರಿಸಿದ್ದರೆ, ಬ್ರೌಸರ್ ಹೋಗಲಾಗದ ಸ್ಥಳಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ನ ಯಾವುದೇ ಬದಲಾವಣೆ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಸುರಕ್ಷಿತ ಮತ್ತು ಅಸುರಕ್ಷಿತ ಮೂಲ URL ಗಳನ್ನು ನಿಮ್ಮ ಮುಂದಿರುವ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಎರಡರಲ್ಲಿ ಒಂದರಲ್ಲಿ ಅಸಂಗತಿ ನೀವು ನೋಡುತ್ತಿರುವ ಮರುನಿರ್ದೇಶನವನ್ನೇ ಉತ್ಪಾದಿಸುತ್ತದೆ.

ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಹೆಡರ್ಗಳು ಒಂದು ಒಪ್ಪಂದ

TLS ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನಲ್ಲಿ ಕೊನೆಗೊಂಡಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಸರಳ HTTP ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಬೇರೆ ರೀತಿ ಹೇಳಬೇಕು. ಆಫ್ಲೋಡರ್ ಹೆಡರ್ ಸೆಟ್ಟಿಂಗ್ ಪ್ರಾಕ್ಸಿ ಹೊಂದಿಸುವ ಹೆಡರ್ನ ಹೆಸರನ್ನು ನೀಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ರೋಟೋಕಾಲ್, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕೀಮ್ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಅದನ್ನು ನಂಬುತ್ತದೆ.

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

ಲೂಪ್ ಸೆಷನ್ ಆದಾಗ, ಮಾರ್ಗವಲ್ಲ

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

ಸಾಬೀತಾದ ಅಸಂಗತಿಯನ್ನು ಅದರ ಮಾಲೀಕನಲ್ಲಿ ಸರಿಪಡಿಸಿ, ಅದು ಮೂಲ URL, ಕುಕಿ ಡೊಮೇನ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಒಪ್ಪಂದವಿರಬಹುದು, ನಂತರ ಒಂದು 302 ಕಣ್ಮರೆಯಾಗುವುದನ್ನು ನೋಡುವ ಬದಲು ಇಡೀ ನ್ಯಾವಿಗೇಷನ್ ಅನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಲೂಪ್ ಮುರಿಯಲು HTTPS ಅಗತ್ಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಮರುನಿರ್ದೇಶನವನ್ನು ಕೆಟ್ಟ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಬದಲಾವಣೆ ಮುಗಿದ ಮೇಲೆ ಟನೆಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: ತಿಳಿದಿರುವ ಖಾಸಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ವಿನಂತಿಸಿ ಅದು ತಲುಪುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮುಂದಿನ ಮರುನಿರ್ದೇಶನಕ್ಕೆ ಹೋಲಿಸಲು ಸ್ವಚ್ಛ ಆಧಾರ ರೇಖೆ ಇರುವಂತೆ.