ugrás a tartalomhoz

Parancs megerősítése, avagy hol kezdődik a kényelmi funkció?

Joó Ádám · 2006. Ápr. 23. (V), 15.33
Régóta gondolkozom azon, vajon egy szerkesztőfelületen pl a kilistázott elemeknél szükséges-e a törlés link megnyomása után php/html alapú megerősítést kérni (tehát egy új oldalt generálni hozzá), vagy elegendő, ha egy javascriptes confirm ablak ugrik fel. Kikapcsolt javascript esetén ugye a felhasználó elesik ettől a biztonsági funkciótól. Mit gondoltok erről?
‹ Email címemre adatokat küldő űrlap (Frontpage) Auto resize IE-ben ›
 ■
1

JS

janoszen · 2006. Ápr. 23. (V), 15.36
Szerintem, a JS elég, mert a) gyorsabb b) akinél ki van kapcsolva a JS, az többnyire tudja, mit csinál. Ha meg nem, úgy kell neki. :)

Engem többnyire zavar, de lehet, hogy másokat nem. Ne nézzen hülyének az oldal. :) Persze, akkor azért mondjuk jelöld pirossal a gombot, véletlenül ne nyomja meg a user. :)
9

Biztonság, CSRF

Hodicska Gergely · 2006. Ápr. 23. (V), 19.37
Ne nézzen hülyének az oldal. :)

Ez nem csak erről szól. A megerősítést kérő oldalnak akár komoly biztonsági szerepe is lehet. Érdemes utánaolvasnod egy kevésbé ismert támadási módszernek: cross-site request forgeries.


Felhő
11

Nem validált bemenet

janoszen · 2006. Ápr. 23. (V), 21.19
Ne haragudj, ezzel nem számoltam.

Általában ha beérkezik egy HTML bemenet, leparsolom és kiszűröm belőle a nem engedélyezett tag-eket és/vagy attribútumokat. Miután sikerült elég gyorsra megírni, az ilyesmivel nem szokott baj lenni, ezért nem is gondoltam rá, hogy máshol baj lehet.

A munkamenet kezelés meg úgyszint biztonságos (amennyire az lehet, ugye) de a törlő oldalakat nem lehet csak úgy crossdomain meghívni. :)
12

gondold át egy kicsit

Hodicska Gergely · 2006. Ápr. 23. (V), 22.43
Ez egy elég érdekes támadási mód, és pont ezért elég sokan (jelen eset is ezt mutatja ;)) nem értik meg a lényegét. Itt nem elég az, hogy Te véded a saját alkalmazásod direkt módon. Azzal csak az XSS támadási módok ellen védekezel, az CSRF támadhatóság még megmarad. Pont elég az, hogy ha van tetszőleges XSS támadható (vagy csak épp engedékeny) a Tiedtől független oldal, amit felhasználó nézegetni szokott miközben használja a Te webes rendszeredet, és a third party sütik engedélyezve vannak (ez sok böngésző esetében alapértelmezett).

Szóval ez ellen nem tudsz az általad említett módon védekezni, csak a cikkben szerepelt (vagy azokhoz hasonló) módszerek felhasználásval.


Felhő
2

Undo

attlad · 2006. Ápr. 23. (V), 15.49
Feldobált confirm ablak is idegesítő lehet, ha sokszor kell törölni. Egy megoldás: törölheti közvetlenül, de minden utolsó műveletet vissza lehet vonni.

Az is könnyen megoldható, hogy JS esetén confirm és nincs megerősítő oldal, JS nélkül (nincs confirm) van kikapcsolható megerősítő oldal.

(+ A törlő "gomb" semmiképp se sima link legyen.)
3

Kikapcsolt javascript

Anonymous · 2006. Ápr. 23. (V), 16.01
Megint ez a kikapcsolt javascript...
Egy szerkesztőfelületet megrendelésre, adott emberek számára készül.
Vehetjük alapnak azt, hogy ilyenkor meghatározhatjuk, hogy a szerkesztőfelületet milyen böngészővel, hova kapcsolt javascripttel tudja használni a megrendelő.
Tapasztalat szerint ez menni szokott. Egy alkalommal sikerült egy egész szerkesztőség számára Firefox-ot telepíttetnem, azóta is azt használják, pedig csak egy pici dolog volt, ami ideiglenesen IE-ben nem működött.

A javascriptes confirm egyébként elég szokott lenni, az undo-s megoldás is jó lehet, bár sokkal bonyolultabb leprogramozni. A rákérdezés viszont amiatt jobb szerintem, mert minden felhasználó megszokta, hogy törlés előtt először van egy confirm.

Gyulus
5

Nem csak...

janoszen · 2006. Ápr. 23. (V), 16.57
Kedves Gyulus!

Minek magyarázzam, már elmondtam: nem csak admin felületen lehet szükség ilyesmire. Ezer másik helyen is. Mire jó a szűk látókör? Nyilván okkal tette föl a kérdező a kérdést.

J
8

kérdést nem olvastad?

Hodicska Gergely · 2006. Ápr. 23. (V), 19.32
A kérdésből azért kiderül, hogy itt adminfelületről van szó, ráadásul a helyedben jobban megnézném, hogy kinek mondod, hogy szűklátókörű. :(


Felhő
10

Olvastam...

janoszen · 2006. Ápr. 23. (V), 21.15
...a kérdést, de két kezemen meg tudom számolni azokat a projekteket, ahol később nincs további kérés, fejlesztés, és volt már szerencsém ilyen módosításhoz is. Mindazonáltal a téma erre a kérdésre terjedt ki, ezért hasznos kitárgyalni azt is, hogy mi van akkor, ha nem csak az adminfelületen van szükség rá.
14

Olvastad...

Anonymous · 2006. Ápr. 23. (V), 22.47
Szóval a kérdés szerkesztő felületre vonatkozott. Én arra válaszoltam. A másik az, hogy hirtelen nem nagyon tudok olyan programot elképzelni, ahol a mezei felhasználó valamilyen adatot törölhet a rendszerből. Tudnál segíteni, milyen programban töröl adatot a felhasználó?

Gyulus
4

checkbox

Anonymous · 2006. Ápr. 23. (V), 16.20
én pl. checkbox-ot rakok az ilyen "durva" gombok mellé, amit mindenképp X-elnie kell...
6

Legjobb...

janoszen · 2006. Ápr. 23. (V), 16.58
Azt hiszem, hogy ez a legjobb megoldás. Adott esetben azt is meg lehet csinálni, hogy ha elfelejtette kipipálni, akkor dobja fel a JS ablakot, amely utólag kipipálja, a submit úgyis utána megy.
7

ha sok van

erenon · 2006. Ápr. 23. (V), 17.17
Ha sok van, akkor ugyanúgy pipálni kell, bár egy törlésére elég jó.
Sokelemű halamzokból sok darabot kitörölni szerintem a legegyszerűbb úgy ha többet lehet kijelölni, például a checkboxot a dolog elé kell rakni, és akkor más művelet is végeszhető egyel is, többel is.
13

Egyet értek

Pred · 2006. Ápr. 23. (V), 22.44
Akár egy rekordot, akár többet kell törölni, elég biztonságos a checkbox módszer (kipipálom, mit akarok törölni/módosítani/akármi) és csak utána nyomok rá egy elég feltűnően piros törlés gombra. Ehhez még hozzátenném, hogy ne legyen félrekatt, legyen elég távol a törlés a többi vezérlőtől..
15

HTML || JS

sly · 2006. Ápr. 24. (H), 00.18
Lehetséges egy olyan megoldási is, hogy ha van JS, akkor confirm-ot használ a böngésző, ha nincs akkor rákérdező oldalt.