Új hozzászólás Aktív témák

• Sk8erPeter nagyúr

  #2833

  #2831 Karma

  2012-08-22 17:26:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #2831 Karma

  #2831 Karma

  Direkt kitértem arra, amikor csak simán böngészgeted a Facebookot Nézd meg a Chrome Developer Toolsával, mit is kommunikál le az oldal a backendjével: minden kéréshez csatolja a session ID-t. Még egy hótegyszerű statikus oldal, mint a Prohardver is folyton küldi az azonosítót.

  Hogy most az URL-ben van, vagy a headerekben, cookieban vagy más formában, az teljesen mindegy. Nehezen tudok elképzelni olyan szisztémát, amelyben ez az elem teljesen hiányzik. Hogy máshogy döntené el, hogy az adott kérés milyen felhasználóhoz tartozik? A HTTP állapotmentes, abban meg nem szabad bízni, hogy az adott IP cím végén ugyanaz az ember van (spoofolni elég egyszerű...).

  Na jó, egyet el tudok, és a hideg ráz tőle azonnal: a usernév/passwordöt elküldeni minden kéréssel

  Apropó Liferay, igen, mindig generálja ezeket. Ha nem használod a JSR-186/286-ot nagyon nem részletezném, a fő hogy mindig

  Fontosszerk: Ja látom konkrétan az URL-ben passzolgatást kifogásoltad... Szerintem egyenértékűek, na

  Jó, hogy ilyen hosszan leírtad a dolgot, meg korábban már én is többféleképpen kifejtettem, aztán a "Fontosszerk.:" résznél végre rájöttél, miről beszéltem addig.
  Lehet, hogy biztonsági szempontból egyenértékű (bár ez számomra nem feltétlenül egyértelmű, bár igen, adott esetben valóban "lehallgatható" a kommunikáció, ha valaki nagyon akarja, és akkor lehet, hogy mindegy, hogy URL-ben vagy headerben vagy cookie-ban vagy más ügyeskedéssel passzolod át az adatot; bár ha URL-lel passzolod, legalább megkönnyíted a dolgát ), de felhasználói élmény tekintetében nagyon nem. Ha az URL össze van okádva egy baromi hosszú hash-sel, amikor böngészgetek, az szerintem nagyon zavaró, plusz az URL nem lesz könnyen megjegyezhető, mert az átlaguser nem biztos, hogy szét tudja választani a
  http://example.com/foo/bar/test
  címet ettől:
  http://example.com/foo/bar/test?asd=jalskdjq34lkj321sadnlasdequwel&bla=123lknasdl678sadlok

  Ezenkívül akkor a felhasználó ezt a hányadékot menti el a könyvjelzőkhöz is.
  Szóval szerintem ha lehet, kerülendő a session id URL-ben történő passzolgatása. Jó, hát XHR-nél kb. le van szarva, mert abból a felhasználó többnyire lószart sem vesz észre, de a böngésző címsorába ne legyen beokádva ez a fenti rondaság.
  Így már oké?

• sztanozs veterán

  #2832

  #2831 Karma

  2012-08-22 17:14:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #2831 Karma

  #2831 Karma

  Direkt kitértem arra, amikor csak simán böngészgeted a Facebookot Nézd meg a Chrome Developer Toolsával, mit is kommunikál le az oldal a backendjével: minden kéréshez csatolja a session ID-t. Még egy hótegyszerű statikus oldal, mint a Prohardver is folyton küldi az azonosítót.

  Hogy most az URL-ben van, vagy a headerekben, cookieban vagy más formában, az teljesen mindegy. Nehezen tudok elképzelni olyan szisztémát, amelyben ez az elem teljesen hiányzik. Hogy máshogy döntené el, hogy az adott kérés milyen felhasználóhoz tartozik? A HTTP állapotmentes, abban meg nem szabad bízni, hogy az adott IP cím végén ugyanaz az ember van (spoofolni elég egyszerű...).

  Na jó, egyet el tudok, és a hideg ráz tőle azonnal: a usernév/passwordöt elküldeni minden kéréssel

  Apropó Liferay, igen, mindig generálja ezeket. Ha nem használod a JSR-186/286-ot nagyon nem részletezném, a fő hogy mindig

  Fontosszerk: Ja látom konkrétan az URL-ben passzolgatást kifogásoltad... Szerintem egyenértékűek, na

  Igen, a fontosszerk a lényege a dolognak. GET nem szép POST/Header/(cookie) preferált.

Új hozzászólás Aktív témák