Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
autor |
sõnum |
|
andrusny
Kreisi kasutaja
liitunud: 20.03.2006
|
20.01.2008 19:40:09
post andmete kustutamine |
|
|
On leht, millelt saadetakse formiga andmed teisele, seal toimub midagi ja suunatakse kolmandale. Kui nüüd minna back noolega tagasi teisele ja teha reload, on need andmed ikka veel post osas sees ja leht käitub nagu oleks talle andmed saadetud. Kas on kuidagi võimalik öelda, et post andmed kustutataks peale nende lugemist?
_________________
|
|
Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
tagasi üles |
|
|
Telempe
Kreisi kasutaja
liitunud: 02.11.2002
|
20.01.2008 20:58:58
|
|
|
Käitub selle pärast nii, et brauser saadabki post andmed uuesti.
_________________ ORLY? I hardly know her! |
|
Kommentaarid: 22 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
21 |
|
tagasi üles |
|
|
andrusny
Kreisi kasutaja
liitunud: 20.03.2006
|
20.01.2008 21:06:32
|
|
|
Kas neid kuidagi kustutada ei anna peale saatmist, et uut saatmist ei toimuks?
_________________
|
|
Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
tagasi üles |
|
|
mikk36
HV Guru
liitunud: 21.02.2004
|
20.01.2008 21:55:58
|
|
|
andrusny kirjutas: |
Kas neid kuidagi kustutada ei anna peale saatmist, et uut saatmist ei toimuks? |
andmetega pane kaasa id ning iga id salvesta ära et mis on seal lehel käinud
ja kui tuleb juba seal lehel olnud id, siis pane ignoreerima post infot (ehk kustutada ise _POST sisu ära)
|
|
Kommentaarid: 85 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
2 :: |
78 |
|
tagasi üles |
|
|
andrusny
Kreisi kasutaja
liitunud: 20.03.2006
|
20.01.2008 22:01:09
|
|
|
Tänud, täitsa hea plaan.
_________________
|
|
Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
tagasi üles |
|
|
i8080
Kreisi kasutaja
liitunud: 15.03.2002
|
21.01.2008 12:52:13
|
|
|
vanasti oli korrektne lahendus sel puhul http-headerites Location reaga manipuleerimine.
formi postitamise aadress peaks olema pandud mingisugune algsest erinev aadress, post teate kätte saamisel server uuelt aadressilt serveerib ühe "tühja" lehe kus http-headeris viitab tagasi algsele (enne postitamist olnud) aadressile. sel juhul browseri back ei tekita topelt postitusi, kuna sellele teisele postitatud aadressile ta ei liigu.
|
|
Kommentaarid: 165 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
148 |
|
tagasi üles |
|
|
tanzanite
HV kasutaja
liitunud: 13.05.2006
|
21.01.2008 13:02:57
|
|
|
andrusny kirjutas: |
Tänud, täitsa hea plaan. |
Ei, see on _halb_ plaan. sick1 plaan on parem.
|
|
tagasi üles |
|
|
andrusny
Kreisi kasutaja
liitunud: 20.03.2006
|
21.01.2008 13:34:13
|
|
|
Aga kui ma liigun mitte ühe vaid kaks astet tagasi olen ju ikka sellel post lehel. Hetkel realiseerisin selle random generaatoriga plaani ja peaks suht kindel olema. Saatmis formi genereeritakse ühele väljale suva number, nüüd järgmisel lehel võtab andmebaasist eelmine kord salvestatud numbri ja võrdleb seda uue numbriga, kui on erinevad, salvestab uue andmebaasi asemele ja jätkab ka muude post andmete salvestust, kui aga numbrid kattuvad liigutakse kohe lehelt välja.
Edit:miks sa ütled, et see halb on?
_________________
|
|
Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
tagasi üles |
|
|
Supiplex
HV veteran
liitunud: 11.12.2002
|
21.01.2008 15:43:55
|
|
|
sick1 lahendus on igati piisav. Proovi järele, kui ei usu.
Aga kui sa tahad "oma" lahendust teha, siis kindlasti mitte juhusliku arvuga. Kasuta lihtsalt loendurit. Andmebaasis on lihtsalt üks väli, millest loed endale uue numbri välja ja siis suurendad seda ühe võrra. Näiteks postgre-s oli täpselt selle jaoks sequence nimeline elukas.
Väldi iga hinna eest juhuslike arvude kasutamist identifikaatoritena. ID-d peavad olema sellised, et sa saad neile 100% loota. Kõige usaldusväärsem ongi lihtne loendur.
Miku häkk on halb mitmel põhjusel. Peamiselt seetõttu, et IP ei ole usaldusväärne kriteerium kliendi unikaalsuse kontrolliks. Sama IP tagant võib tulla kümme tuhat erinevat klienti, sinu koodile paistaksid nad kõik ühe kliendina. Lisaks, dünaamilisi IP aadresse roteeritakse sulle märkamatult. Sama klient võib ühe reloadi ajal tulla ühelt IP-lt ja järgmise ajal järgmiselt. Mobiilkliendid, load balancing, veel mõned asjad teevad muid trikke.
_________________ The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions. |
|
Kommentaarid: 38 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
34 |
|
tagasi üles |
|
|
mikk36
HV Guru
liitunud: 21.02.2004
|
21.01.2008 18:05:32
|
|
|
Supiplex kirjutas: |
sick1 lahendus on igati piisav. Proovi järele, kui ei usu.
Aga kui sa tahad "oma" lahendust teha, siis kindlasti mitte juhusliku arvuga. Kasuta lihtsalt loendurit. Andmebaasis on lihtsalt üks väli, millest loed endale uue numbri välja ja siis suurendad seda ühe võrra. Näiteks postgre-s oli täpselt selle jaoks sequence nimeline elukas.
Väldi iga hinna eest juhuslike arvude kasutamist identifikaatoritena. ID-d peavad olema sellised, et sa saad neile 100% loota. Kõige usaldusväärsem ongi lihtne loendur.
Miku häkk on halb mitmel põhjusel. Peamiselt seetõttu, et IP ei ole usaldusväärne kriteerium kliendi unikaalsuse kontrolliks. Sama IP tagant võib tulla kümme tuhat erinevat klienti, sinu koodile paistaksid nad kõik ühe kliendina. Lisaks, dünaamilisi IP aadresse roteeritakse sulle märkamatult. Sama klient võib ühe reloadi ajal tulla ühelt IP-lt ja järgmise ajal järgmiselt. Mobiilkliendid, load balancing, veel mõned asjad teevad muid trikke. |
ma pole mingit ip kontrolli pakkunud
pigem oli mõte et kasvõi sessiooni id võtta et kui on teatud aja jooksul külastanud antud lehte, siis ei toimi see enam samamoodi nagu esimene kord
|
|
Kommentaarid: 85 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
2 :: |
78 |
|
tagasi üles |
|
|
andrusny
Kreisi kasutaja
liitunud: 20.03.2006
|
21.01.2008 19:12:59
|
|
|
tsitaat: |
Väldi iga hinna eest juhuslike arvude kasutamist identifikaatoritena. |
Aga see ei ole ju mingi identifikaator seal. Arv peab olema lihtsalt erinev, et kood tööle hakkaks. Oletame, et vana arv oli 100 kas on siis vahe, kui uus on 101 või 3002 ? Muidugi juhusliku arvuga võib tekkida olukord, et tuleb sama arv, mis oli eelmine kord, kuid piisavalt suure valiku puhul on selline võimalus minimaalne. Selles suhtes oleks järjest liitmine kindlam.
_________________
|
|
Kommentaarid: 7 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
7 |
|
tagasi üles |
|
|
Supiplex
HV veteran
liitunud: 11.12.2002
|
21.01.2008 23:47:23
|
|
|
mikk36 kirjutas: |
ma pole mingit ip kontrolli pakkunud
pigem oli mõte et kasvõi sessiooni id võtta et kui on teatud aja jooksul külastanud antud lehte, siis ei toimi see enam samamoodi nagu esimene kord |
Ok. Sain valesti aru.
andrusny kirjutas: |
tsitaat: |
Väldi iga hinna eest juhuslike arvude kasutamist identifikaatoritena. |
Aga see ei ole ju mingi identifikaator seal. Arv peab olema lihtsalt erinev, et kood tööle hakkaks. Oletame, et vana arv oli 100 kas on siis vahe, kui uus on 101 või 3002 ? Muidugi juhusliku arvuga võib tekkida olukord, et tuleb sama arv, mis oli eelmine kord, kuid piisavalt suure valiku puhul on selline võimalus minimaalne. Selles suhtes oleks järjest liitmine kindlam. |
See on sessiooni ajutine identifikaator. Justnimelt, peab olema erinev. Loenduri puhul on arvud alati unikaalsed. Juhusliku arvu korral ei ole. Nii võib igasugu põnevaid bugisid sisse tulla - hoolimata sellest, et sa arvad kollisiooni võimaluse minimaalse olevat. Ära usalda arvutit ja tema juhuarvude generaatorit. Mis veelgi olulisem - ära usalda iseennast. Mida rohkem nurki sa sirgeks lõikad, seda rohkem vigu sa asemele kirjutad.
_________________ The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions. |
|
Kommentaarid: 38 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
1 :: |
34 |
|
tagasi üles |
|
|
tanzanite
HV kasutaja
liitunud: 13.05.2006
|
22.01.2008 10:28:41
|
|
|
andrusny kirjutas: |
Edit:miks sa ütled, et see halb on? |
back nupu funktsionaalsus rikutud:
* kasutajalt küsitakse (friggin popup) kas ta tahab (ei ta ei taha - aga enamasti vajutatakse suvalist nuppu ja teadet ennast reeglina ei loeta) uuesti postitada.
* ... - ilma et kasutaja üldse näeks mida ta postitab (mitte et tavakasutaja üldse aru saab mida see tegevus tähendab).
* vajad ekstra koodi (toimiv on kaugel triviaalsusest), et kaitsta mitmekordsete soovimatute postituste eest. + käitumine kui avastasid topelt postitamise.
* just don't do it.
Soovitatav käitumine:
* postitatakse form
* töödeldakse form (ei väljastata midagi)
* header "Location" redirect (kus siis teavitad kasutajad asjade seisust [done / failed / whatever]) - see ütleb brauserile, et leht mida kuvada on teises kohas (seega käesolevat postitust pole mõtet meeles pidada)
* die / exit
|
|
tagasi üles |
|
|
|