Коомдук форма жөнөтмөлөрүн жеке тармакка кантип импорттоо керек

Бир коомдук форма жөнөтмөсүн кабыл алуу жазуусунан жеке импорттоочуга чейин көзөмөлдөп, текшерүү, эсептик маалыматтар жана кайра аракетти туура тарапта кармаңыз.

Жеке тармак менен эч качан сүйлөшпөгөн коомдук форма да жеке тармак баалоого тийиш болгон маалыматты чыгарат. Туннель ким кимге кайрыларын гана өзгөртөт. Жүктөөдөн кийинки бардык нерсе — импорт чечими жана ал жеке тарапка таандык. Бул колдонмо бир жөнөтмөнү браузерден ички жазууга чейин көзөмөлдөйт.

Жөнөтмө түшкөн жерден баштаңыз

Браузер коомдук акыркы чекитке сурам жөнөтөт, ал көзөмөлдөнгөн кабыл алуу кампасына сап жазат жана ырастоодон башка эч нерсе кайтарбайт. Ошол кампа — өткөрүп берүү чекити жана ал коомдук катмар жаза алган жалгыз нерсе болушу керек. Чийки маалыматты ошол жерде өзгөртпөй, келген убактысы жана туруктуу жазуу идентификатору менен бирге сактаңыз.

Андан кийин жеке кызматкер туннель аркылуу күтүп турган саптарды тартып алып, ар бири менен эмне кылууну чечет. Ал өзүнүн идентификациясы менен иштейт, бул кийинки бөлүмдүн темасы.

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

Алгачкы эки сап ар башка ички абалда бүтүшү керек, ал эми үчүнчүсү экинчисин түзүүнүн ордуна ошол баштапкы жазуу үчүн мурун бекитилген идентификаторду кайтарышы керек. Башка кандайдыр бир жыйынтык импорттун дагы кайталанууга жараксыз экенин билдирет.

Тектеш макалалар