Paano Mag-import ng mga Isinumite sa Pampublikong Form sa Isang Pribadong Network

Ang pampublikong form na hindi kailanman nakikipag-usap sa pribadong network ay gumagawa pa rin ng datos na kailangang hatulan ng pribadong network. Binabago lamang ng tunnel kung sino ang tumatawag kanino. Ang lahat pagkatapos ng pag-download ay desisyon sa pag-import, at kabilang ito sa pribadong panig. Sinusundan ng gabay na ito ang isang isinumite mula sa browser hanggang sa naitalang panloob na talaan.

Magsimula Kung Saan Dumadapo ang Isinumite

Nagpapadala ang browser sa isang pampublikong endpoint, na nagsusulat ng isang hilera sa kontroladong imbakan ng pagtanggap at walang ibinabalik kundi isang pagkilala. Ang imbakan na iyon ang punto ng paghahatid, at dapat itong maging tanging bagay na masusulatan ng pampublikong antas. Panatilihin doon ang hilaw na nilalaman nang hindi binabago, kasama ang oras ng pagdating at isang matatag na identifier ng talaan.

Pagkatapos ay hinihila ng pribadong manggagawa ang mga nakabinbing hilera sa pamamagitan ng tunnel at nagpapasya kung ano ang gagawin sa bawat isa. Tumatakbo ito sa ilalim ng sarili nitong pagkakakilanlan, at iyon ang paksa ng susunod na seksyon.

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

Bigyan ang Importer ng Autoridad na Kailangan Lamang

Ang pampublikong proseso ng web at ang pagkakakilanlang nagsusulat sa panloob na aplikasyon ay dapat na dalawang magkaibang prinsipal. Ang pampublikong server ay hindi nangangailangan ng panloob na administrasyon dahil lamang kailangan nitong maghatid ng datos ng form, at ang isang shared account para sa dalawang panig ay ginagawang panloob na pagsulat ang anumang bug sa web. Bigyan ang manggagawa ng sarili nitong kredensyal, limitahan ito sa isang operasyon ng pag-import, at itala kung aling prinsipal ang nagsagawa ng bawat pag-import. Ang paghihiwalay na iyon ang nagbibigay-kahulugan sa hangganan ng tunnel kaysa sa palamuti lamang.

Limitahan din kung saang pinagmulan maaaring magbasa ang manggagawa. Kung gumagamit ang implementasyon ng pila o serbisyo ng paglilipat, pinapanatili ng serbisyong iyon ang sarili nitong authentication at patakaran sa pag-access, dahil hindi nagpapatunay ang VPN ng anuman sa loob ng payload.

Ang panandaliang function ay hindi rin exempted sa parehong pagsusuri. Habang tumatakbo ito, ang posisyon nito sa network at ang mga kredensyal nito ay nagbibigay pa rin ng autoridad, at ang mas maikling buhay ay nagpapaliit lamang ng bintana. Ang buhay ay hindi kapalit ng pagpapasya kung aling mga operasyon ang maaaring isagawa ng pagkakakilanlan.

I-validate Bago Magbago ang Anumang Panloob

Ang mga field ng pampublikong form ay tekstong kontrolado ng attacker hanggang mapatunayang salungat, at ang gabay ng OWASP sa validation ng input ay isinama ang mga backend feed sa hindi mapagkakatiwalaang pinagmulan dahil na rin doon. Sinasabi ng naka-encrypt na paglilipat na dumating nang buo ang mga byte, hindi na inilalarawan nito ang isang pinapayagang kahilingan. I-parse at i-validate bago ang anumang privileged na hakbang, upang ang masamang hilera ay hindi kailanman makarating sa code path na maaaring kumilos.

Tukuyin ang mga pinapayagang field, ang mga format nito, ang mga sukat nito at ang mga business rule na dapat mapanatili. Ang petsa ay maaaring maayos ang format at mali pa rin para sa hinihiling na operasyon, at ang payload na nagpangalan ng panloob na account o status ng pag-apruba ay hindi dapat makapagbigay sa sarili nito ng alinman sa dalawa.

Ipadala ang mga tinanggihang hilera sa isang resulta ng pagsusuri sa halip na hulaan ang isang pagwawasto o ipasa ang mga ito sa isang shell o hilaw na interface ng database. Itala ang identifier ng talaan at ang nabigong tuntunin, hindi ang bawat field na tina-type ng aplikante.

Gumawa ng Punto ng Muling Pagsubok sa Isang Operasyon

Kung ang talaang submission-1042 ay hinila nang dalawang beses dahil nawala ang unang pagkilala, kailangan ng manggagawa ng matibay na paraan upang makilala ang pinagmulang talaan at ang naitalang resulta nito. Ang iskedyul na nagpapatakbo ng trabaho nang isang beses ay hindi nagpapatunay na ang bawat hilera ay inilapat nang isang beses. Ang dobleng paghahatid ay normal, kaya dapat itong saluhin ng disenyo.

Gamitin ang sariling transaksyon at mekanismo ng paghawak ng duplicate ng panloob na aplikasyon, at panatilihin ang identifier ng pinagmulan, ang resulta at ang pagkilala sa isang magkakaugnay na pagkakasunod-sunod. Kumpirmahin lamang pagkatapos na ang nilalayong operasyon ay naitala o permanenteng naitalaga, at huwag kailanman burahin ang hilera ng pagtanggap dahil lamang na-download ang mga byte.

Pagkatapos ay patunayan ito gamit ang tatlong fixture: isang wastong hilera, isang maling format na hilera, at ang parehong kontroladong identifier ng pinagmulan na inihahatid nang dalawang beses. Ang bawat isa ay dumadaan sa parehong endpoint na ginagamit ng manggagawa.

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

Ang unang dalawang hilera ay dapat magtapos sa magkaibang panloob na estado, at ang pangatlo ay dapat ibalik ang identifier na naitala na para sa pinagmulang talaang iyon sa halip na lumikha ng pangalawa. Anumang iba pa ay nangangahulugan na ang pag-import ay hindi pa nauulit.