Nola inportatu formulario publikoen bidalketak sare pribatura

Jarraitu formulario publiko baten bidalketa bat sarrerako erregistrotik inportatzaile pribatura, eta mantendu balidazioa, kredentzialak eta berriro saiakera alde egokian.

Sare pribatuarekin inoiz hitz egiten ez duen formulario publiko batek sare pribatuak epaitu behar dituen datuak sortzen ditu oraindik ere. Tunelak soilik aldatzen du nor norekin harremanetan jartzen den. Deskargaren ondorengo guztia inportazio erabakia da, eta alde pribatuarena da. Ibilbide honek bidalketa bat jarraitzen du nabigatzailetik barne erregistro finkatu bateraino.

Hasi bidalketa lurreratzen den tokian

Nabigatzaileak amaiera-puntu publiko batera bidaltzen du, eta horrek errenkada bat idazten du kontrolatutako sarrera biltegian, eta ez du ohar bat baino gehiago itzultzen. Biltegi hori da entrega-puntua, eta maila publikoak idatz dezakeen gauza bakarra izan beharko luke. Eutsi han karga gordina aldatu gabe, iritsi zen orduarekin eta erregistro identifikatzaile egonkorrarekin batera.

Ondoren, langile pribatu batek zain dauden errenkadak tunelen bidez ateratzen ditu eta bakoitzarekin zer egin erabakitzen du. Bere identitatearen pean exekutatzen da, eta hori da hurrengo atalaren gaia.

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

Emaiozu inportatzaileari behar duen autoritatea besterik ez

Web prozesu publikoak eta barne aplikazioan idazten duen identitateak bi subjektu desberdin izan beharko lukete. Zerbitzari publiko batek ez du barne administraziorik behar formulario datuak entregatu behar dituelako bakarrik, eta bi aldeen kontu partekatu bakar batek edozein web akats barne idazketa bihurtzen du. Emaiozu langileari bere kredentziala, mugatu inportazio eragiketa bakarrera, eta erregistratu zein subjektuk egin zuen inportazio bakoitza. Bereizketa horrek egiten du tunelaren muga esanguratsu eta ez apaingarri.

Mugatu langileak zein iturritatik irakur dezakeen ere. Inplementazioak ilara bat edo transferentzia zerbitzu bat erabiltzen badu, zerbitzu horrek bere autentifikazioa eta sarbide politika gordetzen ditu, VPNak ez baitu ezer autentifikatzen kargaren barruan.

Iraupen laburreko funtzio bat ez dago berrikuspen beretik salbuetsita. Exekutatzen den bitartean, bere sare posizioak eta kredentzialek autoritatea ematen dute oraindik, eta bizitza laburragoak leihoa estutzen du soilik. Iraupenak ez du ordezkatzen identitateak zein eragiketa egin ditzakeen erabakitzea.

Balidatu barnean ezer aldatu aurretik

Formulario publikoen eremuak erasotzaileak kontrolatutako testua dira kontrakoa frogatu arte, eta OWASPren sarreraren balidazio jarraibideek backend fluxuak iturri fidagaitzen artean kokatzen dituzte hain zuzen ere arrazoi horregatik. Transferentzia zifratuak byteak osorik iritsi zirela esaten du, ez eskaera onargarri bat deskribatzen dutela. Analizatu eta balidatu pribilegiatutako urrats bakoitzaren aurretik, errenkada txar bat inoiz jardun dezakeen kode bide batera irits ez dadin.

Definitu onartutako eremuak, haien formatuak, haien tamainak eta bete beharreko negozio arauak. Data bat ondo eratua egon daiteke eta hala ere okerra izan eskatutako eragiketarako, eta barne kontu bat edo onespen egoera bat aipatzen duen kargak ezin du bere buruari horietako bat ere eman.

Bidali baztertutako errenkadak berrikuspen emaitz batera, zuzenketa bat asmatu edo shell batera edo datu basearen interfaze gordin batera birbidali beharrean. Erregistratu erregistro identifikatzailea eta huts egin duen araua, ez eskatzaileak idatzitako eremu guztiak.

Egin berriro saiatzeko puntu bat eragiketa batean

submission-1042 erregistroa bi aldiz ateratzen bada lehen oharra galdu delako, langileak modu iraunkorra behar du iturri erregistroa eta haren emaitza finkatua ezagutzeko. Lana behin exekutatzen duen ordutegi batek ez du frogatzen errenkada bakoitza behin aplikatu zenik. Entrega bikoitza normala da, beraz diseinuak xurgatu behar du.

Erabili barne aplikazioaren beraren transakzio eta bikoiztuak kudeatzeko mekanismoa, eta mantendu iturri identifikatzailea, emaitza eta oharra sekuentzia koherente batean. Berretsi aurreikusitako eragiketa finkatu edo modu iraunkorrean esleitu ondoren bakarrik, eta ez ezabatu inoiz sarrera errenkada byteak deskargatu direlako soilik.

Gero frogatu hiru proba fitxategirekin: errenkada baliodun bat, errenkada gaizki eratutako bat eta kontrolatutako iturri identifikatzaile bera bi aldiz entregatuta. Bakoitzak langileak erabiltzen duen amaiera-puntu beretik igarotzen da.

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

Lehen bi errenkadek barne egoera desberdinetan amaitu behar dute, eta hirugarrenak iturri erregistro horretarako jadanik finkatuta dagoen identifikatzailea itzuli behar du, bigarren bat sortu beharrean. Beste edozein gauzak esan nahi du inportazioa oraindik ez dela errepikagarria.

Erlazionatutako artikuluak