VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಮಿಶ್ರ ವಿಷಯ ಇನ್ನೂ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ: ಏನನ್ನು ಸರಿಪಡಿಸಬೇಕು

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

ಸುರಂಗವು ಉಪ-ಸಂಪನ್ಮೂಲವನ್ನು ಏಕೆ ಆವರಿಸಲಾರದು

ಮಿಶ್ರ ವಿಷಯದ ಪ್ರಾರಂಭ ಸಾಮಾನ್ಯ HTTP ಮೇಲೆ ಉಪ-ಸಂಪನ್ಮೂಲವನ್ನು ಕೇಳುವ HTTPS ದಾಖಲೆಯಿಂದ. ಪ್ರತಿ URL ತನ್ನದೇ ಸ್ಕೀಮ್ ಆಧಾರದಲ್ಲಿ ತೀರ್ಪು ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂಲ ದಾಖಲೆಯ ರಕ್ಷಣೆ ಎಂದಿಗೂ ಸಂತಾನ ವಿನಂತಿಗೆ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ಬ್ರೌಸರ್ನ ಕೆಳಗೆ ಸೇರಿಸಿದ ಎನ್ಕ್ರಿಪ್ಶನ್ ತಂತಿಯ ಮೇಲೆ ಹೋಗುವುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಮಾರ್ಕ್ಅಪ್ ಕೇಳಿದ http:// ಅನ್ನಲ್ಲ.

ಪ್ರಸ್ತುತ ಬ್ರೌಸರ್ಗಳು ಈ ವಿನಂತಿಗಳನ್ನು ಎರಡು ಗುಂಪುಗಳಾಗಿ ವಿಭಜಿಸಿ ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸುತ್ತವೆ. ಸ್ಕ್ರಿಪ್ಟ್ಗಳು, ಸ್ಟೈಲ್ಶೀಟ್ಗಳು, iframe ಮತ್ತು fetch, XMLHttpRequest ಅಥವಾ WebSocket ಮೂಲಕ ಮಾಡಿದ ಕರೆಗಳು ಮುಂಚಿತ ಅಪ್ಗ್ರೇಡ್ ಪ್ರಯತ್ನವಿಲ್ಲದೆ ನೇರವಾಗಿ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತವೆ. ಚಿತ್ರಗಳು, ಆಡಿಯೊ ಮತ್ತು ವಿಡಿಯೊ https:// ಆಗಿ ಮತ್ತೆ ಬರೆಯಲಾಗಿ ಮತ್ತೆ ಕೇಳಲಾಗುತ್ತವೆ, ಆ ಸುರಕ್ಷಿತ ಸಂಗ್ರಹಣೆ ವಿಫಲವಾದಾಗ ಲೋಡಿಂಗ್ ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ. ಯಾವ ಉಪ-ಸಂಪನ್ಮೂಲದ ಹೋಸ್ಟ್ ಬರಿಯ IP ವಿಳಾಸವೋ ಆ URL ಅಪ್ಗ್ರೇಡ್ನಿಂದ ಹೊರತುಪಡಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ IP ಹೋಸ್ಟ್ನಲ್ಲಿ HTTP ಚಿತ್ರ ಮೌನವಾಗಿ ಸರಿಪಡಿಸಲ್ಪಡುವ ಬದಲು ನಿರ್ಬಂಧಿತವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಈ ವಿಭಜನೆ, ಅಪ್ಗ್ರೇಡ್ ಆಗಬಹುದಾದ ಬದಿಯಲ್ಲಿನ ಆ ವಿನಾಯಿತಿ ಸಹಿತ, ಇಲ್ಲಿ ದಾಖಲಾಗಿದೆ: Mozilla ನ ಮಿಶ್ರ ವಿಷಯ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ. Chrome ಸುರಕ್ಷಿತ ಪುಟದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಅಸುರಕ್ಷಿತ ಡೌನ್ಲೋಡ್ಗಳಿಗೂ ಇದೇ ರೀತಿಯ ನಿರಾಕರಣೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುತ್ತಮುತ್ತಲಿನ ಪುಟ ಸದೃಢವಾಗಿ ಕಂಡಾಗ PDF ಲಿಂಕ್ ಸಾಯಬಹುದು.

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

ಅಸುರಕ್ಷಿತ ಉಲ್ಲೇಖ ಯಾರದ್ದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಸಮಸ್ಯೆಯ URL ಅನ್ನು ಅದು ಎಲ್ಲಿ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ ಎಂಬ ಆಧಾರದಲ್ಲಿ ವಿಂಗಡಿಸಿ. ಆ ಉತ್ತರವೇ ನೀವು ಇಂದು ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದೇ, ಪೂರೈಕೆದಾರರು ಒಂದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕೇ, ಅಥವಾ ಅವಲಂಬನೆ ಪುಟವನ್ನು ಬಿಡಬೇಕೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದನ್ನು ನೆಟ್ವರ್ಕ್ ಪ್ಯಾನೆಲ್ನ Initiator ಅಂಕಣದಲ್ಲಿ ಓದಿ, ಏಕೆಂದರೆ ಪರದೆಯ ಮೇಲಿನ ಮಾರ್ಕ್ಅಪ್ ಸಾಮಾನ್ಯವಾಗಿ ರನ್ಟೈಮ್ನಲ್ಲಿ ಜೋಡಿಸಲ್ಪಡುತ್ತದೆ.

ಹೋಸ್ಟ್ ಈಗಾಗಲೇ 443ರಲ್ಲಿ ಉತ್ತರಿಸುತ್ತಿದ್ದು, ಉಲ್ಲೇಖ ಮಾತ್ರ http ಎಂದು ಹೇಳಿದರೆ, ಸರಿಪಡಿಸುವಿಕೆ ಸ್ಥಳೀಯವಾಗಿದೆ: ಉಲ್ಲೇಖ ಬದಲಿಸಿ, ಪುಟದ ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸಿ ಮತ್ತು ಸಾಲು https ಆಗಿರುವುದನ್ನು ದೃಢೀಕರಿಸಿ. ಪೋರ್ಟ್ 80ರಲ್ಲಿ ಮಾತ್ರ ಆಲಿಸುವ ಹೋಸ್ಟ್ ಅನ್ನು ಸಂಪಾದನೆಯಿಂದ ಅನುಗುಣಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಂಪನ್ಮೂಲ ಸ್ಥಳಾಂತರಗೊಳ್ಳುತ್ತದೆ, ಅದರ ಮುಂದೆ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿರುವುದನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ, ಅಥವಾ ಅದು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಟ್ಯಾಗ್ ಮ್ಯಾನೇಜರ್ ಸೇರಿಸಿದ URL ನಿಮ್ಮ ಸ್ವಂತ ಟೆಂಪ್ಲೇಟ್ ಸ್ವಚ್ಛವಾಗಿದ್ದಾಗಲೂ ಕಾಣಿಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ರಕರಣವು ನಿಖರವಾದ URL ಮತ್ತು ಕನ್ಸೋಲ್ ಸಾಲು ಲಗತ್ತಿಸಲಾದ ಟಿಕೆಟ್ಗೆ ಸೇರುತ್ತದೆ. ಸಿಬ್ಬಂದಿಗೆ ಅಸುರಕ್ಷಿತ ವಿಷಯವನ್ನು ಅನುಮತಿಸಲು ಹೇಳುವುದು ಈ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಆ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಭೇಟಿ ನೀಡುವ ಪ್ರತಿ ಸೈಟ್ಗೂ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ.

ಬ್ರೌಸರ್ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ, ಉಲ್ಲೇಖವನ್ನು ಸರಿಪಡಿಸಿ

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

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

ಎರಡು ಸಹಾಯಕ ನಿಯಂತ್ರಣಗಳು ತಿಳಿಯಲು ಯೋಗ್ಯವಾದವು ಮತ್ತು ಯಾವುದೂ ಸರಿಪಡಿಸುವಿಕೆಗೆ ಪರ್ಯಾಯವಲ್ಲ. Content-Security-Policy ಹೆಡರ್ upgrade-insecure-requests ಬ್ರೌಸರ್ ಪುಟ ಬಿಡುವ ಮೊದಲು http ಉಪ-ಸಂಪನ್ಮೂಲ URL ಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದು ನೀವು ಇನ್ನೂ ಕಂಡುಹಿಡಿಯದ ಹಳೆಯ ಉಲ್ಲೇಖಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಮತ್ತೆ ಬರೆದ ವಿನಂತಿ ಗುರಿ ಹೋಸ್ಟ್ HTTPS ಒದಗಿಸದಿದ್ದರೆ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಡರ್ ಬ್ರೌಸರ್ ಯಾವ URL ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ. HSTS ಪ್ರತಿ ಹೋಸ್ಟ್ಗೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಅಂದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್ನಲ್ಲಿನ ನೀತಿ ಈ ಹೆಡರ್ ಎಂದೂ ಕಳುಹಿಸದ ಮೂರನೇ ಪಕ್ಷದ CDN ಗೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಟೆಂಪ್ಲೇಟ್ ಬದಲಿಸಿದ ನಂತರ ಪುಟದ ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸಿ ಮತ್ತು ರೆಂಡರ್ ಆದ HTMLನಲ್ಲಿ ಹಳೆಯ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಅದೇ URL ಒಂದು ಭಾಗ, ಅನುವಾದ ಸ್ಟ್ರಿಂಗ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಕ್ಷೇತ್ರದ ಮೂಲಕವೂ ಬರಬಹುದು.

ರೀಡೈರೆಕ್ಟ್ಗಳನ್ನೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ, ಏಕೆಂದರೆ https:// ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಸರಪಳಿ http:// ಸ್ಥಳದಲ್ಲಿ ಇಳಿಯಬಹುದು ಮತ್ತು ಬ್ರೌಸರ್ ಕೊನೆಯ ಜಿಗಿತವನ್ನು ತೀರ್ಪು ಮಾಡುತ್ತದೆ. ಎರಡನೇ ಆದೇಶದ -L ರೂಪವು ಮೇಲಿನ ಆ ಪರಿಣಾಮಕಾರಿ URL ಅನ್ನು ನಿಮಗಾಗಿ ಮುದ್ರಿಸುತ್ತದೆ. ಕೊನೆಯ ಜಿಗಿತ ಶುದ್ಧ http ಆಗಿದ್ದರೆ, ನೀವು ಸಂಪಾದಿಸಿದ ಲಿಂಕ್ ಚೆನ್ನಾಗಿ ಕಂಡರೂ ಉಲ್ಲೇಖ ಇನ್ನೂ ತಪ್ಪಾಗಿದೆ.

ಕನ್ಸೋಲ್ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಪ್ಯಾನೆಲ್ನೊಂದಿಗೆ ಪುಟವನ್ನು ದೃಢೀಕರಿಸಿ

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

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

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