Bad request vagy access denied?
Szerintetek olyan esetben, amikor az illetőnek nincs joga az adott művelethez és mellette még formailag hibás kérést is küld, akkor melyik hibaüzenetet adjam vissza neki?
Ha a business logic felett ellenőrzöm a jogosultságot, akkor a bad request a könnyebben megvalósítható, ha a representation felett ellenőrzöm a jogosultságot, akkor az unauthorized a könnyebben megvalósítható. Vajon biztonsági kockázat e, hogy először a formai hibákat ellenőrzöm, és csak utána a jogokat?
■ Ha a business logic felett ellenőrzöm a jogosultságot, akkor a bad request a könnyebben megvalósítható, ha a representation felett ellenőrzöm a jogosultságot, akkor az unauthorized a könnyebben megvalósítható. Vajon biztonsági kockázat e, hogy először a formai hibákat ellenőrzöm, és csak utána a jogokat?
Bad Request
Ha HTTP statusz kodokat hasznalsz, arra figyelj, hogy a 403 Forbidden szabvany szerint azt jelenti, hogy az adott eroforras nem erheto el es ezen smemilyen jogosultsag nem valtoztat:
A 401-es header pedig kifejezetten csak a WWW-Authenticate headerrel hasznalhato.
A formai hibát a 400-nál arra
A 401-el tisztában vagyok, de nagyon egyszerű custom www-auth header-t írni, szóval az nem probléma.
A 403-at azt nem tudtam (így divat használni REST-nél), mit javasolsz helyette?
sto-n teljes az egyet nem értés ezzel kapcsolatban: rest-http-status-codes
Update:
A 400 helyett ebben az értelemben a 422 Unprocessable Entity, ami szerintem is jobb megoldás. Szóval a kérdés arra vonatkozott...
A 403 oké
Ez teljesen jól leírja a jogosultsággal kapcsolatos részt.
Azaz hiába próbálkozol ugyanezzel a kéréssel, valószínűleg ugyanez marad a helyzet. Használj más hitelesítő adatokat (jelentkezz be megfelelő júzerrel).
De persze az is lehet, hogy a vonal végén ott csücsül egy figyelmes admin, aki ad jogokat az erőforrásra, ekkor természetesen az eddig hibás credential már feljogosít a műveletre (azért van SHOULD NOT, és nem MUST NOT).
A 403 nekem is megfelelt
Az eredeti kérdés arra vonatkozott, hogy az ellenőrzéssel vagy a jogosultsággal kapcsolatos hiba kerüljön e felszínre?
Én alapból a jogosultságosat választanám, mert akinek nincs joga hozzáférni egy rendszerhez, annak semmi köze ahhoz, hogy az hogyan validálja a beérkező adatokat. Viszont megvalósítás szempontjából ez nem logikus, mert ha többféle UI van egy alkalmazáshoz, akkor nyilván a DRY miatt nem fogom ugyanazt a jogosultság ellenőrzést különböző formában betenni mindegyikbe, hanem inkább a business logic elé teszek egy szűrőt, az elé meg adaptereket minden egyes UI-hoz. Az adapterekben történik a validáció egy része, ott konvertálja át query-re vagy command-re a bejövő http request-eket a rendszer, így a konvertálás közben történő hibákat akár jogosultság ellenőrzés nélkül is vissza tudná dobni...
Valahogy nem stimmel ez az egész. Ha a command bus-ra teszem a jogosultság ellenőrzést, akkor már létrejött a command, és csak a kezelését akadályozom meg azzal, hogy ellenőrzöm a jogosultságot. Bár végülis az életben is így megy, próbálkozhat valaki parancsolgatni, ha nincs joga hozzá, akkor nem foglalkoznak a parancsaival...
A Bad Request a protokoll
REST vs RPC
Egy gyengén tipusos nyelvben valószínűleg egy külön lépés, a validáció fog szólni ha számként nem értelmezhető string jön egy propertyben. Egy erősen tipusos nyelvben viszont már az unmarshalling során parzoljuk az értékeket, tehát itt már hozzá sem férünk a request objektumhoz ha formai hiba van az értékekben.
Vagyis... gyengén tipusos környezetben mindkét viselkedés megoldható, erősen tipusosban csak a második. Talán konzisztensebb, ha a második viselkedést valósítjuk meg (vagyis formai validáció authorization előtt), függetlenül attól, hogy épp miben van megírva a szerveroldal.
Rendben, köszönöm, akkor
Szerintem megválaszoltad
Életszerűbb is, hogy ha nincs kulcsod egy ajtóhoz, akkor ne tudd kinyitni, nem pedig a biztonsági őr tegye ki a szűrödet. :) Pont ezt csinálod, ha
Szerintem az életben úgy megy, hogy ahhoz, hogy elkezdj parancsolni próbálkozni, előbb fel kell juss a parancsnoki hídra. Utána jön még az üzleti logika (és/vagy további jogosultság-ellenőrzés), hogy az adott parancsra neked van-e elég csillag a válladon.
Analógia-smalanlógia
Bonyolódik a történet :D
Kimaradt