Ajax authentikációval
2015-01-24T19:30:00+01:00
2015-01-29T15:36:37+01:00
2022-07-19T03:22:09+02:00
  • Most meg azt olvastam, hogy van olyan, hogy Back-end as a Service (BaaS), amit pl. a Kinvey, Parse, 42Cloud API is szolgáltat.
    A fejlesztőknek még el is magyarázzák, hogy hogyan kell a biztonságot biztosítani.

    Most már látom, hogy igazából ezt kerestem én.
    Mutasd a teljes hozzászólást!
  • Másképp hogy csinálod? A te PHP-d tud rendetlen fejű HTTP válaszokat küldeni?

     Inkább csak szembesültem azzal a ténnyel, hogy én a php-ból igazából csak az echo-t használtam eddig. Azt láttam, hogy a nodejs-nél foglalkoztak a headerrel is , de a php tutorialok nem igazán jelezték, hogy van header is. Egyszerűen volt egy echo.
    Most meg felfedeztem a meleg vizet. A http, a nevével összhangban egy protokoll.

    Ezért már megérte felkelni ma reggel.
    Mutasd a teljes hozzászólást!
  • A szerver részéről tehát logikus olyan http csomagokat küldeni, amiknek van rendes fejük és ott lehet küldeni a 200/404/401 ... státuszkódokat ?

    Másképp hogy csinálod? A te PHP-d tud rendetlen fejű HTTP válaszokat küldeni?

    Így nem kell saját protkollt írni, hiszen használhatom a http-ét.

    Még ha a szerver oldalon implementálnál is saját protokollt, a böngésző nem tudna róla, és ő bizony továbbra is a jó öreg HTTP protokollal küldené a kéréseket és értelmezné a válaszokat. (Na jó, van websocket, de az már teljesen más kategória, na meg régebbi böngészők nem is mind tudják.)

    Amivel szerintem mindenképp érdemes megismerkedni a HTTP protokollból, és az RFC-nek megfelelően használni:
    - Kérés metódusok megfelelő használata (GET csak módosulást nem okozó lekérésre, PUT csak új entitás létrehozására vagy meglevő felülírására, DELETE csak entitás törlésére, a POST meg jolly-joker, ami jó minden olyanra, amit a többiek nem fednek le).
    - Válasz státusz kódok megfelelő használata (2xx siker, 3xx átirányítás, 4xx kliens hiba, 5xx szerver hiba, de ezen belül is a helyzethez leginkább illeszkedő kódot jó választani)
    - Alap szintű cache mechanizmus: Cache-Control illetve Expires header, esetleg Age és Vary header-ök.

    Ezzel el lehet kerülni, hogy az ember újra fel akarja találni a meleg vizet, vagy esetleg a protokoll ellenében próbáljon elérni valamit. (Példa: random-generált cache-busting query paraméter küldése a kliensről, mert a kliens vagy a szerver nem tud/akar egy megfelelő "Cache-Control: no-cache" headert küldeni...)
    Mutasd a teljes hozzászólást!
  • A szerver részéről tehát logikus olyan http csomagokat küldeni, amiknek van rendes fejük és ott lehet küldeni a 200/404/401 ... státuszkódokat ?
    Így nem kell saját protkollt írni, hiszen használhatom a http-ét.
    Innentől a kliens készülhet arra, hogy a bejelentkezéssel kapcsolatos hibákat majd értelmesen fogja a szerver jelezni neki a fejlécben.
    Ez gusztusos megoldásnak tűnik.
    Mutasd a teljes hozzászólást!
  • A szigorúan vett REST stílusban nem használnak sessiont, mert onnantól már nem lesz igaz az, hogy a szerver állapotmentes. Az authentikációt meg lehet oldani valamelyik HTTP authentikációs módszerrel (basic vagy digest), de a lényeg, hogy minden kérés magának authentikál. (A HTTPS használata ajánlott a jelszavak jobb védelme illetve a man-in-the-middle támadások elleni védelem miatt.) A másik megoldás, hogy van egy authentikáló URL-ed, amire a login adatokat elküldve visszaad a szerver egy access tokent, és a későbbi kérések ezzel a tokennel zajlanak. (Ez kicsit olyan, mintha session lenne, de a token itt csak a felhasználó azonosítására szolgál, nem pedig egy menet közben módosuló adattárolót azonosít.)

    Ha böngészős klienseid lesznek főleg, akkor nem feltétlen van értelme a "hivatalos" REST megközelítést követni, az AJAX-os kérések használhatják azt a sessiont, amit a felhasználó amúgy is kapott. Ekkor viszont a kliensnek fel kell készülnie rá, hogy az AJAX kérés hibára futhat. A szép megoldás az, ha az AJAX-os kérések egyértelműen el tudják dönteni, hogy lejárt/érvénytelen authentikáció volt a hiba, vagy valami más. (Pl. a szerver küldhet 401 Unauthorized választ ilyen esetben, amit a kliens speciális esetként kezel, és felszólítja a felhasználót a bejelentkezésre.) A gyakorlatban sok helyen látom, hogy ennyire nem aprózzák el, és a kliens egyszerűen minden hiba esetén felkéri a felhasználót, hogy frissítse meg az oldalt (ott pedig már átirányítódik a normál belépő felületre lejárt session esetén).
    Mutasd a teljes hozzászólást!
  • Összeállt egy kis környezet (PHP-F3, Angularjs), amiben olvasnivaló webtartalom keveredik REST adattartalommal, valamint publikus tartalom jogosultságot igénylő tartalommal.
    Ha valaki olyan tartalmat kér, amihez jogosultság kell, akkor a SESSION-ben ellenőrzöm, hogy belépett-e már, és ha még nem tette meg, akkor reroute-olom a bejelentkező felületre.
    Amikor ezt a módszert a REST szolgáltatásra próbáltam átvinni, akkor rögötn kiderült, hogy szerveroldalon akár használhatnám is ezt a reroute-ot a REST részekre is, de a kliens nem tudna mit kezdeni vele.

    Valami protokollt kell esetleg építeni a REST-re ?

    Üdvözlettel:
    János
    Mutasd a teljes hozzászólást!
abcd