ಸಾರ್ವಜನಿಕ ಫಾರ್ಮ್ ಸಲ್ಲಿಕೆಗಳನ್ನು ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ಗೆ ಆಮದು ಮಾಡುವುದು ಹೇಗೆ

ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ನೊಂದಿಗೆ ಎಂದಿಗೂ ಮಾತನಾಡದ ಸಾರ್ವಜನಿಕ ಫಾರ್ಮ್ ಕೂಡ ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ ತೀರ್ಮಾನಿಸಬೇಕಾದ ದತ್ತಾಂಶವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಸುರಂಗವು ಯಾರು ಯಾರಿಗೆ ಕರೆ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ. ಡೌನ್ಲೋಡ್ ನಂತರದ ಎಲ್ಲವೂ ಆಮದು ನಿರ್ಧಾರವಾಗಿದ್ದು ಅದು ಖಾಸಗಿ ಬದಿಗೆ ಸೇರಿದೆ. ಈ ಮಾರ್ಗದರ್ಶನವು ಒಂದು ಸಲ್ಲಿಕೆಯನ್ನು ಬ್ರೌಸರ್ನಿಂದ ಬದ್ಧವಾದ ಆಂತರಿಕ ದಾಖಲೆಯವರೆಗೆ ಅನುಸರಿಸುತ್ತದೆ.

ಸಲ್ಲಿಕೆ ಬೀಳುವ ಸ್ಥಳದಿಂದ ಪ್ರಾರಂಭಿಸಿ

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

ನಂತರ ಖಾಸಗಿ ಕೆಲಸಗಾರನು ಸುರಂಗದ ಮೂಲಕ ಬಾಕಿ ಇರುವ ಸಾಲುಗಳನ್ನು ಎಳೆದುಕೊಂಡು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತಾನೆ. ಅವನು ತನ್ನದೇ ಗುರುತಿನ ಅಡಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ, ಅದೇ ಮುಂದಿನ ವಿಭಾಗದ ವಿಷಯ.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

ಆಮದುದಾರರಿಗೆ ಬೇಕಾದ ಅಧಿಕಾರ ಮಾತ್ರ ನೀಡಿ

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

ಕೆಲಸಗಾರನು ಯಾವ ಮೂಲದಿಂದ ಓದಬಹುದು ಎಂಬುದನ್ನೂ ನಿರ್ಬಂಧಿಸಿ. ಅನುಷ್ಠಾನವು ಕ್ಯೂ ಅಥವಾ ವರ್ಗಾವಣೆ ಸೇವೆಯನ್ನು ಬಳಸಿದರೆ, ಆ ಸೇವೆ ತನ್ನದೇ ದೃಢೀಕರಣ ಮತ್ತು ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ VPN ಪೇಲೋಡ್ನ ಒಳಗಿನ ಯಾವುದನ್ನೂ ದೃಢೀಕರಿಸುವುದಿಲ್ಲ.

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

ಆಂತರಿಕ ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಮೌಲ್ಯೀಕರಿಸಿ

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

ಅನುಮತಿಸಲಾದ ಕ್ಷೇತ್ರಗಳು, ಅವುಗಳ ಸ್ವರೂಪಗಳು, ಅವುಗಳ ಗಾತ್ರಗಳು ಮತ್ತು ಪಾಲಿಸಬೇಕಾದ ವ್ಯಾಪಾರ ನಿಯಮಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಒಂದು ದಿನಾಂಕ ಸರಿಯಾಗಿ ರೂಪುಗೊಂಡಿದ್ದರೂ ಕೋರಿದ ಕಾರ್ಯಾಚರಣೆಗೆ ತಪ್ಪಾಗಿರಬಹುದು, ಮತ್ತು ಆಂತರಿಕ ಖಾತೆ ಅಥವಾ ಅನುಮೋದನಾ ಸ್ಥಿತಿಯನ್ನು ಹೆಸರಿಸುವ ಪೇಲೋಡ್ ತನಗೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನೀಡಲು ಸಾಧ್ಯವಾಗಬಾರದು.

ತಿರಸ್ಕೃತ ಸಾಲುಗಳನ್ನು ತಿದ್ದುಪಡಿಯನ್ನು ಊಹಿಸುವ ಬದಲು ಪರಿಶೀಲನಾ ಫಲಿತಾಂಶಕ್ಕೆ ಕಳುಹಿಸಿ, ಅಥವಾ ಅವನ್ನು ಶೆಲ್ ಅಥವಾ ಕಚ್ಚಾ ಡೇಟಾಬೇಸ್ ಇಂಟರ್ಫೇಸ್ಗೆ ರವಾನಿಸಬೇಡಿ. ದಾಖಲೆ ಗುರುತು ಮತ್ತು ವಿಫಲವಾದ ನಿಯಮವನ್ನು ದಾಖಲಿಸಿ, ಅರ್ಜಿದಾರರು ಟೈಪ್ ಮಾಡಿದ ಪ್ರತಿ ಕ್ಷೇತ್ರವನ್ನಲ್ಲ.

ಒಂದೇ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಮರುಪ್ರಯತ್ನ ಬಿಂದುವನ್ನು ಮಾಡಿ

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

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

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

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

ಮೊದಲ ಎರಡು ಸಾಲುಗಳು ವಿಭಿನ್ನ ಆಂತರಿಕ ಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬೇಕು, ಮತ್ತು ಮೂರನೆಯದು ಎರಡನೆಯದನ್ನು ಸೃಷ್ಟಿಸುವ ಬದಲು ಆ ಮೂಲ ದಾಖಲೆಗೆ ಈಗಾಗಲೇ ಬದ್ಧವಾದ ಗುರುತನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು. ಬೇರೆ ಯಾವುದೇ ಫಲಿತಾಂಶವೆಂದರೆ ಆಮದು ಇನ್ನೂ ಪುನರಾವರ್ತಿಸಲು ಸಿದ್ಧವಿಲ್ಲ.