सार्वजनिक फॉर्म सबमिशन खाजगी नेटवर्कमध्ये कसे आयात करावे

खाजगी नेटवर्कशी कधीही बोलणार नाही असे सार्वजनिक फॉर्मही खाजगी नेटवर्कला ठरवावी लागणारी माहिती तयार करते। बोगदा फक्त कोण कोणाला कॉल करतो हे बदलतो। डाउनलोडनंतरचे सर्व काही आयातीचा निर्णय असून तो खाजगी बाजूचा आहे। हा मार्गदर्शक एक सबमिशन ब्राउझरपासून नोंदवलेल्या अंतर्गत नोंदीपर्यंत पाहतो।

सबमिशन जिथे पोहोचते तिथून सुरुवात करा

ब्राउझर सार्वजनिक एंडपॉइंटवर पोस्ट करते, जे नियंत्रित स्वीकृती साठवणीत एक ओळ लिहिते आणि पावतीपेक्षा जास्त काहीही परत देत नाही। ती साठवणी हे हस्तांतरणाचे ठिकाण आहे आणि सार्वजनिक स्तराला लिहिण्याची परवानगी असलेली ती एकमेव गोष्ट असावी। कच्चा डेटा तिथे बदल न करता, तो आलेली वेळ आणि स्थिर नोंद ओळखकर्त्यासह ठेवा।

नंतर खाजगी कर्मचारी बोगद्यातून प्रलंबित ओळी ओढून घेतो आणि प्रत्येकासोबत काय करायचे ते ठरवतो। तो स्वतःच्या ओळखीखाली चालतो, आणि तो पुढील विभागाचा विषय आहे।

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

पहिल्या दोन ओळी वेगवेगळ्या अंतर्गत स्थितीत संपल्या पाहिजेत, आणि तिसरीने दुसरी तयार करण्याऐवजी त्या स्रोत नोंदीसाठी आधीच नोंदवलेला ओळखकर्ता परत द्यावा। इतर कोणताही निकाल म्हणजे आयात अजून पुनरावृत्तीयोग्य नाही।