పబ్లిక్ ఫారం సమర్పణలను ప్రైవేట్ నెట్వర్క్లోకి ఎలా దిగుమతి చేయాలి

ప్రైవేట్ నెట్వర్క్తో ఎప్పుడూ మాట్లాడని పబ్లిక్ ఫారం కూడా ప్రైవేట్ నెట్వర్క్ అంచనా వేయాల్సిన డేటాను ఉత్పత్తి చేస్తుంది. టన్నెల్ ఎవరు ఎవరికి కాల్ చేస్తారో మాత్రమే మారుస్తుంది. డౌన్లోడ్ తర్వాత ప్రతిదీ ఒక దిగుమతి నిర్ణయం, మరియు అది ప్రైవేట్ వైపుకు చెందుతుంది. ఈ మార్గదర్శిని ఒక సమర్పణను బ్రౌజర్ నుండి నమోదు చేసిన అంతర్గత రికార్డు వరకు అనుసరిస్తుంది.

సమర్పణ ల్యాండ్ అయ్యే చోటి నుండి ప్రారంభించండి

బ్రౌజర్ ఒక పబ్లిక్ ఎండ్పాయింట్కు పంపుతుంది, అది నియంత్రిత స్వీకరణ నిల్వలో ఒక అడ్డు వరుసను వ్రాసి అంగీకారం కంటే ఎక్కువ ఏమీ తిరిగి ఇవ్వదు. ఆ నిల్వే హ్యాండోవర్ పాయింట్, మరియు పబ్లిక్ పొర వ్రాయగల ఏకైక విషయం అదే ఉండాలి. ముడి డేటాను అక్కడ మార్చకుండా, అది వచ్చిన సమయం మరియు స్థిరమైన రికార్డు గుర్తింపుతో పాటు ఉంచండి.

తర్వాత ప్రైవేట్ కార్మికుడు టన్నెల్ ద్వారా పెండింగ్ అడ్డు వరుసలను లాగి ప్రతిదానితో ఏమి చేయాలో నిర్ణయిస్తాడు. అతను తన స్వంత గుర్తింపు కింద పని చేస్తాడు, అది తదుపరి విభాగం విషయం.

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

మొదటి రెండు అడ్డు వరుసలు వేర్వేరు అంతర్గత స్థితుల్లో ముగియాలి, మరియు మూడవది రెండవదాన్ని సృష్టించడం బదులు ఆ మూల రికార్డుకు ఇప్పటికే నమోదైన గుర్తింపును తిరిగి ఇవ్వాలి. మరే ఇతర ఫలితం అంటే దిగుమతి ఇంకా పునరావృతమయ్యేది కాదు.