Pakartotiniai tarpinio serverio autentifikavimo bandymai ir nepakartojami įkėlimo turiniai
Supraskite, kodėl pakartotiniai autentifikavimo bandymai gali atskleisti vienkartinį įkėlimo srautą, ir sąmoningai pasirinkite ribotą buferizavimą arba pakartojamą turinį.
GET gali autentifikuotis per tarpinį serverį, o POST arba PUT nepavyksta dėl nepakartojamo turinio ar atsukimo klaidos. Paskyra gali būti teisinga: autentifikavimo mainai gali pareikalauti dar vienos užklausos, kai klientas jau sunaudojo įkėlimą.
| Turinio šaltinis | Pakartojimo pasirinkimas |
|---|---|
| Mažas baigtinis turinys | Ribota buferis gali išsaugoti jo baitus. |
| Ieškoma byla | Kliento palaikoma atsukimo sąsaja gali padaryti jį pakartojamą. |
| Generatorius, vamzdis arba tiesioginis gamintojas | Vienkartinis šaltinis gali reikalauti kitos konstrukcijos. |
libcurl dokumentuoja paieškos atgalinius iškvietimus naudojimui, įskaitant kelių etapų autentifikavimą. Jersey siūlo buferinį ir padalytą objektų apdorojimo režimus, priklausomai nuo jungties elgsenos. Jersey 2 Apache jungties pavyzdys rodo buferinį nustatymą. Nė vienas jų nepadaro neapribotų įkėlimų atmintyje tinkamais.
Atkurkite nepavykstantį metodą ir turinio šaltinį. Parengiamasis GET neturi įkėlimo, kurį būtų galima pakartoti, ir neįrodo, kad vėlesnis įkėlimas dalijasi jo ryšiu ar autentifikavimo būsena. Naujas tikslas, kliento objektas ar ryšio politika gali tai pakeisti. Byla pagrįstas turinys ir tiesioginis srautas taip pat skiriasi, net kai jų pavyzdinis tekstas tas pats.
Jei buferizuojate, apibrėžkite dydžio ribą, saugojimo vietą ir galiojimo laiką. Vienu metu atliekami įkėlimai padaugina išlaidas, o neskelbtini duomenys lieka ten, kur laikoma buferis.
Išankstinė autentifikacija žinomam suderinamam tarpiniam serveriui gali išvengti vieno pradinio iššūkio. Tačiau ji negali pašalinti kiekvieno vėlesnio autentifikavimo rato, peradresavimo ar uždaryto ryšio, kuriam gali prireikti dar vieno bandymo.
Laikykite kartu tarpinio serverio atsakymą, turinio sunaudojimo tašką ir pakartojimo klaidą. Tada atskirkite protokolo pakartojimą nuo neaiškaus programos rezultato: pateikimas galėjo būti apdorotas prieš pametant jo atsakymą. Prieš siųsdami dar kartą, laikykitės tikslo idempotentiškumo taisyklių.