सार्वजनिक फारम बुझाइहरू निजी नेटवर्कमा कसरी आयात गर्ने

निजी नेटवर्कसँग कहिल्यै नबोल्ने सार्वजनिक फारमले पनि निजी नेटवर्कले मूल्याङ्कन गर्नुपर्ने डेटा उत्पादन गर्छ। सुरुङले कसले कसलाई सम्पर्क गर्छ भन्ने मात्र बदल्छ। डाउनलोडपछिको सबै कुरा आयातको निर्णय हो, र त्यो निजी पक्षको हो। यो मार्गदर्शनले एउटा बुझाइलाई ब्राउजरदेखि अभिलेख गरिएको आन्तरिक रेकर्डसम्म पछ्याउँछ।

बुझाइ जहाँ पुग्छ त्यहींबाट सुरु गर्नुहोस्

ब्राउजरले सार्वजनिक अन्त्य बिन्दुमा पठाउँछ, जसले नियन्त्रित प्राप्ति भण्डारमा एउटा पङ्क्ति लेख्छ र स्वीकृतिभन्दा बढी केही फर्काउँदैन। त्यो भण्डार नै हस्तान्तरण बिन्दु हो, र सार्वजनिक तहले लेख्न सक्ने एक मात्र वस्तु त्यही हुनुपर्छ। कच्चा डेटा त्यहीं अपरिवर्तित राख्नुहोस्, त्यो आएको समय र स्थिर रेकर्ड पहिचानकर्तासहित।

त्यसपछि निजी कर्मचारीले सुरुङमार्फत बाँकी पङ्क्तिहरू तान्छ र प्रत्येकसँग के गर्ने भन्ने निर्णय गर्छ। त्यो आफ्नै पहिचानमा चल्छ, र त्यो अर्को खण्डको विषय हो।

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

पहिला दुई पङ्क्ति फरक आन्तरिक अवस्थामा अन्त्य हुनुपर्छ, र तेस्रोले दोस्रो सिर्जना गर्नुको सट्टा त्यो स्रोत रेकर्डका लागि पहिले नै अभिलेख भएको पहिचानकर्ता फर्काउनुपर्छ। अरू कुनै नतिजाको अर्थ आयात अझै दोहोर्याउन योग्य छैन।