ugrás a tartalomhoz

Session adatbázissal

Anonymous · 2005. Júl. 21. (Cs), 11.50
Helló!

Az oldalamhoz szeretnék egy beléptető, regisztráló rendszert nem mással mint session-nel. A gond ott kezdődik, hogy nem cookieval vagy fájllal, hanem adatbázissal. Addig még meg tudom csinálni, hogy a sessionid-t meg az egyéb adatokat eltárolom egy táblában, de hogyan fogom 'kiszedni', hogy minden oldal megkapja a sessionid-t? Van erre valami gyári függvény, vagy nekem kell megírni?
‹ Űrlapokból érkező 'ő' betűk hibásak mysql_list_dbs hiba free kiszolgálón ›
 ■
1

Nem kell megírni

Poetro · 2005. Júl. 21. (Cs), 14.25
Már minden létezik ezuügyben...
Ha a sessiont adatbázisban akarod tárolni, arra is van megoldás:
http://hu.php.net/session
Ajánlom figyelmedbe a session_set_save_handler illetve a session_id függvényt.
--------
Poetro
2

A manualt már nézegettem

Anonymous · 2005. Júl. 21. (Cs), 17.30
A manualt már nézegettem és hagyományos módon (cookie, url) meg tudom oldani. A cookies megoldás jó lenne, ha nem lehetne letiltani a cookiek fogadását. Az url-es meg állítólag (ami mondjuk tényleg könnyen belátható) nem biztonságos. Persze nem akarok én überbrutál biztonsági rendszert az oldalamon, de azért mégis legyen valami, amit azért 'ECDL vizsgával nem lehet feltörni'. Ezért gondoltam, hogy akkor legyen adatbázisos session kezelés, viszont MAGYAR nyelvű leírást nem találtam. (TUDOM, hogy angol tudás nélkül nem fogok megélni, de sajnos (egyenlőre) az angol tudásom nem üti meg azt a mértéket, hogy az angol nyelvű leírást (akár a manualt) olvassak). Szóval leginkább egy egyszerű példára lenne szükségem magyarázattal (ha kérhetek ilyet), amiből megérthetem a dolgot.

Ha valaki tud ilyennel szolgálni, akkor előre is köszönöm.
3

nincs helyette más

Hojtsy Gábor · 2005. Júl. 21. (Cs), 23.34
Valamivel lehetővé kell tenned, hogy egy felhasználótól mindig ugyanazt a session azonosítót kapd vissza, és a webcímben, POST-ban és sütiben való továbbküldésnél erre más megoldás nincs. Érdemes elolvasni erről szóló cikksorozatunkat.
4

Akkor valamit nem értek...

Anonymous · 2005. Júl. 22. (P), 14.04
Az adatbázisos session kezelést nem azért használják, hogy kiváltsák vele a hagyományos session kezelést??

Egyébként az url-es megoldás jó lenne, csak valahogyan azonosítani kellene a felhasználót. IP-re gondoltam először, csak hát mi van ha router mögül netezik (pl. iskola). MAC cím jó lenne, csak azt meg állítólag nem tudom kideríteni PHP-val.

Most akkor mi lenne a jó megoldás?
5

nem azt váltja ki az adatbázis

Hojtsy Gábor · 2005. Júl. 22. (P), 14.45
A PHP a munkamenethez kapcsolódó adatokat a fájlrendszerben tárolja alapból, ezt ki lehet váltani. A szerver oldali adatbázis semmit nem segít neked abban, hogy a felhasználóval tudasd, és tőle visszakérd a munkamenet azonosítót (mint ahogy a fájlrendszer sem segít benne), úgyhogy a süti és a GET/POST változókat használják erre a célra.
6

Értem. De ha a cookie sem

Anonymous · 2005. Júl. 22. (P), 15.45
Értem. De ha a cookie sem jó(mert ugyebár nem engedélyezi mki), az url-ben való továbbítás sem a legjobb, akkor hogy kellene ezt csinálni?. Mondjuk azt azért nem értem, hogy erre nem gondoltak a PHP fejlesztői?

Szerinted mi lenne az ideális (viszonylag biztonságos) megoldás?

A sessionid-t nem tudom elrejteni az url-ben?
7

Használd default

Anonymous · 2005. Júl. 22. (P), 20.36
Használd default beállítással a session kezelést. Session id-t cookie-ba rakja, ha nincs engedelyzve a cookie, akkor meg automatikusan url. Az oldalra meg kiirod, hogy ha nem engelyézi a cookie-t, akkor biztonsági kockázatot vállal.

üdv.: Zsolt
9

cookie használhatóságának ellenőrzése

DevNULL · 2005. Júl. 23. (Szo), 12.33
Van rá mód, hogy ellenőrizzem a felhasználó fogad-e cookie-kat, valami fv-re gondolok. Vagy csak úgy tudom, hogy kiküldök egyet és ha nem jön válasz akkor nem engedélyezi és ezek után használom "default"-ként az url-ben a sessiont???
10

nincs

Hojtsy Gábor · 2005. Júl. 23. (Szo), 13.03
A PHP pontosan az utóbbi módszert alkalmazza. Nem lehet anélkül ellenőrizni, hogy van-e cookie, hogy ne próbálj meg cookie-t küldeni.
8

nincs más

Hojtsy Gábor · 2005. Júl. 22. (P), 20.37
Úgy érzem nem ment át az üzenet. Nem az a helyzet, hogy a PHP fejlesztői nem biztosítanak másik utat, hanem hogy nincs másik út. Ha nem engedélyezik a sütit, akkor kellemetlen, például a php.net-en is van egy csomó kényelmi szolgátatás (my php.net), ha fogadsz sütit, akkor tudod csak igénybe venni. Nem kötelező a felhasználónak a szolgátatlásaidat használni :)
11

igen, sütik nélkül a

Fekete Ferenc GDA · 2005. Júl. 23. (Szo), 16.52
igen, sütik nélkül a yahoo sem enged belépni. A felhasználónak meg kell értenie,h ha használni akarja az internetet, akkor ne tiltsa le a sütiket. Egyébként meg a többség úgysem tiltja le.
Ne parázz már a session miatt, inkább használd!! :)

ferenc voltam
12

OK, nem parázok! :)

Anonymous · 2005. Júl. 23. (Szo), 21.46
Viszont egy kérdésem lenne, mégpedig az hogy amit a sütibe helyez session id-t, azt meg lehet változtatni? Tehát arra gondolok, hogy 'rged4356346t3e4rtert' helyett legyen benne 'ijkhjkhhiá9798798z98tz78t' és persze minden oldal ezt ismerje fel session azonosítónak! Próbáltam, de nekem nem jött össze. (Mondjuk sok gyakorlati haszna nincs(?), csak kíváncsi vagyok inkább.)
13

fogalmam sincs, de

Fekete Ferenc GDA · 2005. Júl. 23. (Szo), 23.18
fogalmam sincs, de úgysincs semmi értelme, hiszen minden sessionid egyedi string.

ferenc voltam
17

session hijacking

Hodicska Gergely · 2005. Júl. 26. (K), 10.19
Már hogy ne lenne értelme. Te bejelentkezel a webbankodba, én is, majd átírom az én sessionid-met a cookie-ban a Tiédre, és máris utalom a lóvét a bankszámládról hozzám. ;)


Felhő
18

Hogy lopod el a szessönt tőlem?

kgyt · 2005. Júl. 26. (K), 10.29
Azért elég nehéz egy szessönt ellopni...
Főleg SSL oldal esetében. Mire visszafejted az 1024bitesen kódolt szessönídét, már nem él a szessön...

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
19

olvasni tessék kérem

Hojtsy Gábor · 2005. Júl. 26. (K), 18.23
Sokaktól böngésző hibákkal el lehet lopni. De jellemzőbb, hogy kapsz egy linket emailben, amire ráklikkelsz (egy általad használt oldalon egy akciós termékre mutató link mondjuk), és az abban a linkben lévé session ID-t fogod használni (tehát ezt a támadó mondja meg). Aztán mivel ezalatt a session ID alatt lépsz be, a támadó kisvártatva ugyanazt az azonosítót használva eléri az adataidat, bankszámlád, stb, amit lehet. Session fixation. Nem véletlenül ajánlottam máshol is ebben a threadben Felhő erről szóló cikkét.
20

Na jó...

kgyt · 2005. Júl. 26. (K), 23.34
Ez Internet Explorer esetén igaz lehet, de egy normális böngészőnél kétlem, hogy el tudod lopni a szessönömet... :-)
Használjon mindenki normális böngészőt, vagy érezze meg a zsebén, hogy nem éri meg a Microsoft selejtes programjával böngészni!

Mellesleg, ha elolvasod a cikket, akkor látod, hogy pont arról beszéltem, mint Felhő (SSL).

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
21

SSL vs. programozói hiba

Hodicska Gergely · 2005. Júl. 27. (Sze), 10.38
Nem teljesen értetted meg Goba példáját. Mivel a PHP sessionkezelése permissive jellegű, ezért ha nincs jól leprogramozva a dolog, akkor könnyen csapdába tudnak ejteni, és tök mindegy, hogy SSL-en vagy vagy sem. Ezért egyik nagyon fontos dolog, hogy beléptetés után egyből válts sessionid-t.


Felhő
23

Banki program

kgyt · 2005. Júl. 27. (Sze), 13.08
Ahol már érdemes a szessön ellopásával bajlódni, ott nem lámákat alkalmaznak...
Értsd, nem alap PHP szessönt fognak alkalmazni, SMS értesítést küldenek minden műveletről, a műveletek késleltetve vannak, stb.

+1
Szvsz alap, hogy törlök minden olyan szessöntídét, ami nincs bejelentkezve, amikor bejelentkezik...
főleg, ha a nem bejelentkezettek nem SSL kapcsolatot használnak.

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
14

lehet, sőt kell is

Hojtsy Gábor · 2005. Júl. 24. (V), 23.12
RTFM: session_id() és session_regenerate_id(), előbbivel te adsz új azonosítót, és akkor azt használja majd, utóbbi automatikusan újat generál. Megjegyzem, a PHP kézikönyv ide vonatkozó részének tartalomjegyzéke (a használható függvények listája az oldalsávban) elférnek egy képernyőn, úgyhogy nem nehéz megtalálni a kapcsolódó függvényeket :)

Komolyan ajánlom figyelmedbe az erről szóló cikkünket, érdemes elolvasni! Például jól megtudhatod belőle, hogy bizony szükséged is lehet az azonosító újragenerálására, ha a session fixation támadások ellen védekezni szeretnél.
15

Sütik és a privacy

Anonymous · 2005. Júl. 25. (H), 15.33
Ugyan nem teljesen ide tartozik, de hátha érdekel valakit. Ha nem szeretnéd, hogy az IE lekorlátozza a sütiket, akkor érdemes P3P kompakt aláírást alkalmazni.

Mi az a P3P? A P3P egy nyílt szabvány, amelyet a W3C ajánl a digitálisan tárolandó adatvédelmi nyilatkozatok számára. Ezt böngészök, mint pl. az IE el tudják olvasni és megfelelöen tudják alkalmazni a biztonsági beállításokat.

ProClub
proclub##kukac##karinthy.hu

ui. csodálkozom, hogy az IE vezetett be elöször és minden teketória nélkül egy nyílt szabványt a böngészöjében...
16

CSS

kgyt · 2005. Júl. 25. (H), 19.29
Nem kell csodálkozni, az IE volt az első amelyben megjelent a CSS.

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
22

Beléptető rendszer

monghuz · 2005. Júl. 27. (Sze), 13.04
Gondolom SQL-ben tárolod a felhasználó adatait, szóval regisztrálásnál elmented az adatokat, esetleg még egy e-mailes aktiválást is betehetsz ha szükségesnek érzed, de igy az elején még nem foglalkoznék vele...

Aztán jön a user, belép és sql-ből kikéred először az adott felhasználó adatait, majd megnézed hogy az imént a formban elküldött név és jelszó megegyezike az adatbázisban szereplóvel (javasolt md5 titkosítás az adatbázisban)

Ha minden stimmol köv lépsben lekéred a felhasználó jogait, nekem erre egy külön jogok táblám van jog_id , jog_nev, jog mezőkkel. (igy minden modulhoz tudok jogokat kiosztani)
a lekért adatokat beírod egy két dimenziós tömbbe valahogy igy =>

$_SESSION["jogok"]["hirek_torles"] = 0 vagy 1
ezután annyi a dolgod hogy a levédentő tartalmadat beteszed egy if-be =>

<?
if ($_SESSION["jogok"]["hirek_torles"] == 1) {
   echo "nagy és titkos tartalom";
} else {
   echo "huzzá regisztrálni";
}
?>
Hát én valahogy igy oldottam meg...

bye Tomi