د عامه فورم سپارنې څنګه خصوصي شبکې ته وارد کړو

عامه فورمه چې هیڅکله له خصوصي شبکې سره نه خبرې کوي، بیا هم هغه معلومات تولیدوي چې خصوصي شبکه باید ارزښت ورکړي. ټنل یوازې دا بدلوي چې څوک چاته زنګ وهل کوي. له ډاونلوډ وروسته هر څه د وارداتو پریکړه ده، او هغه خصوصي خوا ته اړه لري. دا لارښود یوه سپارنه له براوزر څخه تر ثبت شوي داخلي ریکارډ پورې تعقیبوي.

له هغه ځایه پیل کړئ چې سپارنه ورته رسېږي

براوزر عامه پای ټکي ته لیږي، کوم چې په کنټرول شوي ترلاسه کولو ذخیره کې یوه کرښه لیکي او له منښتې پرته نور څه نه بېرته ورکوي. هغه ذخیره د سپارلو نقطه ده، او باید یوازینی شی وي چې عامه پوړ ورته لیکلی شي. خام معلومات هلته بې بدلونه وساتئ، د هغوی د رسېدو وخت او یو ثابت ریکارډ پېژندونکي سره یوځای.

بیا خصوصي کارکوونکی د ټنل له لارې په تمه کرښې راکاږي او پریکړه کوي چې له هر یو سره څه وکړي. هغه د خپل پېژندنې لاندې کار کوي، او دا د بلې برخې موضوع ده.

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

لومړنۍ دوه کرښې باید په جلا داخلي حالتونو کې پای ته ورسیږي، او درېیمه باید د دویمې جوړولو پرځای هماغه سرچینه ریکارډ لپاره دمخه ثبت شوی پېژندونکی بېرته راوګرځوي. هر بل څه معنا دا ده چې واردات لا هم تکرارېدونکي نه دي.