Cloudflare ನ ಬಾಟ್-ಚಾಲೆಂಜ್ (bot-challenge) ವ್ಯವಸ್ಥೆಯು ಸಾಮಾನ್ಯ HTML ಫಾರ್ಮ್ ಸಬ್‌ಮಿಷನ್‌ಗಳನ್ನು ಮೌನವಾಗಿ ವಿಫಲಗೊಳಿಸಬಹುದು, ಇದು ಸರಳ ಪಾವತಿ ಕ್ಲಿಕ್ ಅನ್ನು ನಿಜವಾದ ಬಳಕೆದಾರರಿಗೆ ಅಡೆತಡೆಯನ್ನಾಗಿ ಮಾಡಬಹುದು. ವಿನಂತಿಯನ್ನು (request) ನೇಟಿವ್ ನ್ಯಾವಿಗೇಷನ್ POST ನಿಂದ fetch-first ಫ್ಲೋಗೆ ಬದಲಾಯಿಸುವುದರಿಂದ ಭದ್ರತೆಯನ್ನು ಬಲಪಡಿಸದೆ ಅನುಭವವನ್ನು ಸುಧಾರಿಸಬಹುದು.

ಈ ಸಮಸ್ಯೆ ಏಕೆ ಮುಖ್ಯ?

ಒಬ್ಬ ಡೆವಲಪರ್ ಪ್ರತಿಯೊಂದು ಟೆಸ್ಟ್ ಸೂಟ್, curl ಮತ್ತು ಲೋಕಲ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪಾವತಿ ಫಾರ್ಮ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ್ದರು. ಅದೇ ಫಾರ್ಮ್ ಅನ್ನು ಗ್ರಾಹಕರು Chrome ಬಳಸಿದಾಗ, ಮೊದಲ ಕ್ಲಿಕ್ ನಂತರ ಸೆಕ್ಯೂರಿಟಿ ಎರರ್ ಮತ್ತು ಎರಡನೇ ಕ್ಲಿಕ್‌ನಲ್ಲಿ “timeout-or-duplicate” ಸಂದೇಶವನ್ನು ತೋರಿಸಿತು. ಈ ವೈಫಲ್ಯವು ಮೂರು ಹಾಟ್-ಫಿಕ್ಸ್ ರಿಲೀಸ್‌ಗಳು ಮತ್ತು ಒಂದು ದಿನದ ಸಂಪೂರ್ಣ ડીಬಗ್ಗಿಂಗ್ ಅನ್ನು ಅನಿವಾರ್ಯಗೊಳಿಸಿತು.

ಅಡಗಿರುವ ಸವಾಲು (The hidden edge)

ಈ ಫಾರ್ಮ್ ಒಂದು ಓಪನ್-ಸೋರ್ಸ್ Astro ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿದ್ದು, ಇದು ಸಾಮಾನ್ಯ HTML <form> ಎಲಿಮೆಂಟ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಬಳಕೆದಾರರು Pay ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಸರ್ವರ್ Stripe ಗೆ 303 redirect ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಮತ್ತು ಬ್ರೌಸರ್ ಯಾವುದೇ JavaScript ಇಲ್ಲದೆ ಆ ರಿಡೈರೆಕ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಡಿಸೇಬಲ್ ಮಾಡಿದಾಗ ಪರ್ಯಾಯವಾಗಿ ಸೈಟ್‌ಗಳು ಈ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತವೆ.

Cloudflare ಸೈಟ್‌ನ ಮುಂದೆ ಇರುತ್ತದೆ ಮತ್ತು ಬಾಟ್-ಡಿಟೆಕ್ಷನ್ ಇಂಜಿನ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಸಾಮಾನ್ಯ GET ವಿನಂತಿಗಳಿಗೆ (requests) ಇದು ಇಂಟರ್‌ಸ್ಟೀಶಿಯಲ್ ಚಾಲೆಂಜ್ (ಒಂದು CAPTCHA ಅಥವಾ JavaScript ಚೆಕ್) ಅನ್ನು ತೋರಿಸಬಹುದು. ಬ್ರೌಸರ್ ಚಾಲೆಂಜ್ ಅನ್ನು ಪಾಸಾದ ನಂತರ, ವಿನಂತಿಯು ಮುಂದುವರಿಯುತ್ತದೆ.

ಆದರೆ, ನ್ಯಾವಿಗೇಷನ್ POST ಅನ್ನು ಚಾಲೆಂಜ್‌ಗಾಗಿ ನಿಲ್ಲಿಸಲು ಮತ್ತು ಅದರ ಬಾಡಿಯನ್ನು (body) ಹಾಗೆಯೇ ಉಳಿಸಿಕೊಂಡು ಪುನರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಎಡ್ಜ್ (edge) ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಿ 503 ಸ್ಟೇಟಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇದರಿಂದ ಬ್ರೌಸರ್ ಖಾಲಿ ಪುಟ ಅಥವಾ ಸಾಮಾನ್ಯ ಎರರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. Cloudflare ನಂಬುವ ಅದೇ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಹೊಂದಿರುವ ಸ್ವಯಂಚಾಲಿತ ಟೆಸ್ಟ್ ಬ್ರೌಸರ್‌ಗಳು ಚಾಲೆಂಜ್ ಅನ್ನು ಟ್ರಿಗ್ಗರ್ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಜವಾದ ಬಳಕೆದಾರರು ಸೈಟ್‌ಗೆ ಭೇಟಿ ನೀಡುವವರೆಗೆ ಈ ಸಮಸ್ಯೆ ಗೋಚರಿಸುವುದಿಲ್ಲ.

ಲಾಗ್‌ಗಳು ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸಿದವು?

ಬಳಕೆದಾರರ Chrome ಸೆಷನ್‌ನ ಲೈವ್ ನೆಟ್‌ವರ್ಕ್ ಟ್ರೇಸ್ ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಎರಡು ವಿಭಿನ್ನ ವಿನಂತಿಗಳನ್ನು ತೋರಿಸಿತು:

  • Navigation POST → 503 ಪ್ರತಿಕ್ರಿಯೆ, ಟ್ಯಾಬ್ ಹँगಾಯಿತು.
  • fetch() POST → ವಿನಂತಿ ಪೂರ್ಣಗೊಂಡಿತು.

ಎರಡೂ ವಿನಂತಿಗಳು ಒಂದೇ ಮೂಲದಿಂದ (origin) ಬಂದಿದ್ದವು, ಒಂದೇ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದವು ಮತ್ತು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿದವು. ಏಕೈಕ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ವಿಧಾನ (transport method). fetch ವಿನಂತಿಯು ನ್ಯಾವಿಗೇಷನ್ POST ಗಳನ್ನು ತಡೆಯುವ ಇಂಟರ್‌ಸ್ಟೀಶಿಯಲ್ ಫ್ಲೋ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿತು.

ಎಲ್ಲಿಗೂ ತಲುಪದ ದಾರಿಗಳು

ಡೆವಲಪರ್ ಮೂಲ ಕಾರಣವನ್ನು ತಪ್ಪಿಹೋಗುವಂತೆ ಹಲವಾರು ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದರು:

  • Turnstile ಟೋಕನ್‌ಗಳು ಅವಧಿ ಮುಗಿದಿವೆ ಎಂದು ಭಾವಿಸಿ ಅವುಗಳನ್ನು ನವೀಕರಿಸಿದರು.
  • ಬ್ಲಾಕ್ ಮಾಡಿದ್ದು ಸ್ಥಳದ ಆಧಾರಿತವಾಗಿದೆ ಎಂದು ಭಾವಿಸಿ IP ರೇಂಜ್‌ಗಳನ್ನು ವೈಟ್‌ಲಿಸ್ಟ್ ಮಾಡಿದರು.
  • ಎಕ್ಸ್‌ಟೆನ್ಶನ್‌ಗಳನ್ನು ಡಿಸೇಬಲ್ ಮಾಡಿದರು, ಸರ್ವಿಸ್ ವರ್ಕರ್ಸ್‌ಗಳನ್ನು ಕ್ಲಿಯರ್ ಮಾಡಿದರು ಮತ್ತು ಕುಕೀಗಳನ್ನು ಡಿಲೀಟ್ ಮಾಡಿದರು.

ಪ್ರತಿ ಬದಲಾವಣೆಯೂ ತಪ್ಪನ್ನು ಬದಲಿಸಲಿಲ್ಲ ಏಕೆಂದರೆ ವೈಫಲ್ಯವು ಕ್ಲೈಂಟ್ ಅಥವಾ ಸರ್ವರ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಲ್ಲದೆ, ಎಡ್ಜ್‌ನಲ್ಲಿ (upstream at the edge) ಉಂಟಾಗಿತ್ತು.

ಪ್ರಾಯೋಗಿಕ ಪರಿಹಾರ

Cloudflare ನ ರಕ್ಷಣೆಯನ್ನು ಆಫ್ ಮಾಡುವ ಬದಲಿಗೆ, ಫಾರ್ಮ್ ಅನ್ನು fetch-first ಮಾದರಿಯನ್ನು ಬಳಸುವಂತೆ ಮರು-ಎಂಜಿನಿಯರ್ ಮಾಡಲಾಯಿತು:

  1. ಫಾರ್ಮ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಅದನ್ನು fetch() ಮೂಲಕ JSON ಪೇಲೋಡ್ ಆಗಿ ಕಳುಹಿಸಿ.
  2. ಸರ್ವರ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸಿ. ಸರ್ವರ್ ಪಾವತಿ ಗೇಟ್‌ವೇ ಗಾಗಿ URL ಅನ್ನು ನೀಡಿದರೆ, ಸರಳ GET ವಿನಂತಿಯೊಂದಿಗೆ ಅಲ್ಲಿಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಲು location.assign() ಅನ್ನು ಬಳಸಿ.

Fetch ವಿನಂತಿಗಳು ಇಂಟರ್‌ಸ್ಟೀಶಿಯಲ್ ಚಾಲೆಂಜ್ ಅನ್ನು ಟ್ರಿಗ್ಗರ್ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ POST ವಿನಂತಿಯು ಮೂಲ ಸರ್ವರ್‌ಗೆ ತಲುಪುತ್ತದೆ. ತದನಂತರದ GET ರಿಡೈರೆಕ್ಟ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಯಾವುದೇ ಚಾಲೆಂಜ್ ಮೂಲಕ ಕಳುಹಿಸಬಹುದು, ಏಕೆಂದರೆ GET ಬಾಡಿಗಳು ಖಾಲಿರುತ್ತವೆ ಮತ್ತು ಬಳಕೆದಾರರು ಚಾಲೆಂಜ್ ಅನ್ನು ಪಾಸಾದ ನಂತರ ಅವುಗಳನ್ನು ಮರುಕಳುಹಿಸಬಹುದು.

ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇರುವ ಅಪಾಯಗಳು

  • ಬಳಕೆದಾರರ ನಂಬಿಕೆ: ಮೌನವಾಗಿ ವಿಫಲವಾಗುವ ಪಾವತಿ ಫಾರ್ಮ್ ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ ಮತ್ತು ಆದಾಯದ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
  • ನಿರ್ವಹಣಾ ಹೊರೆ (Maintenance overhead): ಈ ಘಟನೆಯು ಮೂರು ಪ್ಯಾಚ್ ರಿಲೀಸ್‌ಗಳು ಮತ್ತು ಒಂದು ದಿನದ ತನಿಖೆಯನ್ನು ಬಯಲಾಯಿಸಿತು.
  • ಟೆಸ್ಟಿಂಗ್‌ನ ಅಸ್ಪಷ್ಟತೆಗಳು (Testing blind spots): ಕೇವಲ ಆಂತರಿಕ ಟೆಸ್ಟ್ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದು, ನೈಜ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಎಡ್ಜ್-ಕೇಸ್ ವೈಫಲ್ಯಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು.

ವಿಶಾಲ ಸಮುದಾಯಕ್ಕಾಗಿ ಪಾಠಗಳು

  • ನೈಜ ಬ್ರೌಸರ್‌ಗಳನ್ನು ಬಳಸಿ. ಸಮಸ್ಯೆ ಕೇವಲ ನಿಜವಾದ ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಸ್ವಯಂಚಾಲಿತ ಟೆಸ್ಟ್ ರನ್‌ಗಳ ಮೇಲೆ ನಂಬಿಕೆ ಇಡುವ ಬದಲು ಆ ಸೆಷನ್‌ಗಳಿಂದ ನೆಟ್‌ವರ್ಕ್ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ.
  • ಎಡ್ಜ್ ಅನ್ನು ಸ್ಟ್ಯಾಕ್‌ನ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಿ. Cloudflare ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ ಇರುತ್ತದೆ; ಅದರ ವರ್ತನೆಯು ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ರಚಿಸಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುತ್ತದೆ.
  • ಸರಿಯಾದ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಅನ್ನು ಆರಿಸಿ. ನ್ಯಾವಿಗೇಷನ್ POST ಗಳು ಮತ್ತು fetch POST ಗಳು ಎಡ್ಜ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಮಾರ್ಗಗಳ ಮೂಲಕ ಚಲಿಸುತ್ತವೆ. ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು API ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ.
  • ಎರರ್ ವಿವರಗಳನ್ನು ಪ್ರದರ್ಶಿಸಿ. 503 ಅಥವಾ “timeout-or-duplicate” ಸಂದೇಶಗಳನ್ನು UI ನಲ್ಲಿ ತೋರಿಸಿ, ಇದರಿಂದ ಡೆವಲಪರ್‌ಗಳು ಲಾಗ್‌ಗಳನ್ನು ಹುಡುಕದೆ ನಿಖರವಾದ ವೈಫಲ್ಯದ ವಿಧಾನವನ್ನು ನೋಡಬಹುದು.

ಮುಂದೆ ಏನು ಗಮನಿಸಬೇಕು?

ಡೆವಲಪರ್‌ಗಳು ನ್ಯಾಟಿವ್ POST ನ್ಯಾವಿಗೇಷನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಫಾರ್ಮ್-ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಬೇಕು, ವಿಶೇಷವಾಗಿ ಸೈಟ್‌ನ ಮುಂದೆ Cloudflare ಅಥವಾ ಅಂತಹ CDN ಸೆಕ್ಯೂರಿಟಿ ಸೇವೆಗಳು ಇದ್ದಾಗ. ಲೈಟ್‌ವೇಯ್ಟ್ fetch ವ್ಯಾಪರ್ (wrapper) ಅನ್ನು ಸೇರಿಸುವುದು ಇಂತಹ ವೈಫಲ್ಯಗಳನ್ನು ತಡೆಯಬಹುದು. ಎಡ್ಜ್‌ನಿಂದ ಜನರೇಟ್ ಆಗುವ ಸ್ಟೇಟಸ್ ಕೋಡ್‌ಗಳನ್ನು ಕ್ಯಾಪ್ಚರ್ ಮಾಡುವ ಮಾನಿಟರಿಂಗ್ ಟೂಲ್‌ಗಳು, ಸಮಸ್ಯೆ ಗ್ರಾಹಕರನ್ನು ತಲುಪುವ ಮೊದಲೇ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತವೆ.

ಸಾರಾಂಶ: Cloudflare ನ ಬಾಟ್ ಸವಾಲುಗಳು (bot challenges) ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ, ಸಾಮಾನ್ಯ HTML ಫಾರ್ಮ್ ಸಬ್‌ಮಿಷನ್ ಮೌನ ವೈಫಲ್ಯಕ್ಕೆ (silent failure) ತುತ್ತಾಗುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. fetch() ಮೂಲಕ POST ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದು ಮತ್ತು GET ರಿಡೈರೆಕ್ಟ್ ಮೂಲಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು, ಭದ್ರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತಲೇ ಎಡ್ಜ್‌ನ (edge) ಮಿತಿಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಎಡ್ಜ್ ಅನ್ನು ಕೇವಲ ನೆಟ್‌ವರ್ಕ್ ಹಪ್ (network hop) ಎಂದು ಪರಿಗಣಿಸದೆ, ಅದನ್ನು ಕೋಡ್ ಆಗಿ ಪರಿಗಣಿಸಿ ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಿಮ್ಮ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್‌ಗಳನ್ನು (transports) ವಿನ್ಯಾಸಗೊಳಿಸಿ.