Kiel importi publikajn formularsendojn en privatan reton

Sekvu unu publikan formularsendon de la akcepta rikordo ĝis la privata importilo, kaj tenu validigon, akreditaĵojn kaj ripetprovojn ĉe la ĝusta flanko.

Publika formularo, kiu neniam parolas kun la privata reto, tamen produktas datumojn, kiujn la privata reto devas juĝi. La tunelo nur ŝanĝas, kiu alvokas kiun. Ĉio post la elŝuto estas importa decido, kaj ĝi apartenas al la privata flanko. Ĉi tiu trairo sekvas unu sendon de la retumilo ĝis fiksita interna rikordo.

Komencu tie, kie la sendo alteriĝas

La retumilo afiŝas al publika finpunkto, kiu skribas vicon en kontrolitan akceptan konservejon kaj redonas nenion pli ol konfirmon. Tiu konservejo estas la transdona punkto, kaj ĝi devus esti la sola afero, en kiun la publika tavolo povas skribi. Tenu la krudan ŝarĝon tie senŝanĝa, kune kun la alvena tempo kaj stabila rikorda identigilo.

Poste privata laboranto tiras atendantajn vicojn tra la tunelo kaj decidas, kion fari kun ĉiu. Ĝi funkcias sub propra identeco, kio estas la temo de la sekva sekcio.

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

Donu al la importilo nur la rajtigon, kiun ĝi bezonas

La publika reta procezo kaj la identeco, kiu skribas en la internan aplikaĵon, devus esti du malsamaj principaloj. Publika servilo ne bezonas internan administradon nur ĉar ĝi devas liveri formularajn datumojn, kaj unu komuna konto por ambaŭ flankoj igas ĉiun retan cimon interna skribo. Eldonu al la laboranto proprajn akreditaĵojn, limigu ilin al tiu unu importa operacio, kaj registru, kiu principalo plenumis ĉiun importon. Ĝuste tiu apartigo igas la tunelan limon signifa anstataŭ dekoracia.

Limigu ankaŭ, el kiu fonto la laboranto rajtas legi. Se la efektivigo uzas atendovicon aŭ transdonan servon, tiu servo konservas sian propran aŭtentikigon kaj alirpolitikon, ĉar la VPN aŭtentikigas nenion interne de la ŝarĝo.

Mallongdaŭra funkcio ne estas esceptita de la sama revizio. Dum ĝi funkcias, ĝia reta pozicio kaj ĝiaj akreditaĵoj ankoraŭ donas rajtigon, kaj pli mallonga vivo nur mallarĝigas la fenestron. Vivodaŭro ne anstataŭas la decidon, kiujn operaciojn la identeco rajtas plenumi.

Validigu antaŭ ol io interna ŝanĝiĝos

Kampoj de publikaj formularoj estas atakanto-kontrolata teksto ĝis la malo estos pruvita, kaj la gvidlinioj de OWASP pri eniga validigo kalkulas backend-fluojn inter nefidindaj fontoj ĝuste pro tiu kaŭzo. Ĉifrita transdono diras, ke la bajtoj alvenis sendifekte, ne ke ili priskribas permesatan peton. Analizu kaj validigu antaŭ ĉiu privilegia paŝo, por ke malbona vico neniam atingos kodan vojon, kiu povas agi.

Difinu la permesatajn kampojn, iliajn formatojn, iliajn grandecojn kaj la komercajn regulojn, kiuj devas validi. Dato povas esti bone formita kaj tamen malĝusta por la petata operacio, kaj ŝarĝo, kiu nomas internan konton aŭ aproban staton, ne rajtas mem doni al si ajnan el ili.

Sendu malakceptitajn vicojn al revizia rezulto anstataŭ diveni korekton aŭ plusendi ilin al ŝelo aŭ al kruda datumbaza fasado. Registru la rikordan identigilon kaj la malsukcesintan regulon, ne ĉiun kampon, kiun la petanto tajpis.

Starigu ripetpunkton ĉe unu operacio

Se la rikordo submission-1042 estas tirata dufoje ĉar la unua konfirmo perdiĝis, la laboranto bezonas daŭran manieron rekoni la fontan rikordon kaj ĝian fiksitan rezulton. Horaro, kiu plenumas la taskon unufoje, ne pruvas, ke ĉiu vico estis aplikita unufoje. Duobla livero estas normala, do la dezajno devas sorbi ĝin.

Uzu la propran transakcian kaj duplikat-traktan mekanismon de la interna aplikaĵo, kaj tenu la fontan identigilon, la rezulton kaj la konfirmon en unu kohera sinsekvo. Konfirmu nur post kiam la celita operacio estas fiksita aŭ daŭre atribuita, kaj neniam forigu la akceptan vicon nur ĉar la bajtoj estis elŝutitaj.

Poste pruvu tion per tri testaj dosieroj: valida vico, misformita vico, kaj la sama kontrolita fonta identigilo liverita dufoje. Ĉiu el ili trapasas la saman finpunkton, kiun la laboranto uzas.

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

La unuaj du vicoj devas finiĝi en malsamaj internaj statoj, kaj la tria devas redoni la identigilon jam fiksitan por tiu fonta rikordo, anstataŭ krei duan. Io ajn alia signifas, ke la importo ankoraŭ ne estas ripetebla.

Rilataj artikoloj