Toon posts:

[php] Headers/Cookies

Pagina: 1

Acties:

80 views sinds 30-01-2008
Reageer

maandag 20 mei 2002 01:03

Acties:

Verwijderd

Topicstarter

code:

1 2	header("Set-Cookie: sessie=$hash; expires=$datum GMT; path=/"); header("Set-Cookie: userid=$userid; expires=$datum GMT; path=/");

Ik moet 2 cookies met de headers mee sturen, zoals je boven ziet zou je denk geen probleem....

echter hij stuurt alleen de laatste cookie en niet allebei?

edit:
Tikfoutje gemaakt... echter het werkt nog steeds niet

maandag 20 mei 2002 01:12

Acties:

Arjan A

Cenosillicafoob

In PHP is er ook de functie setcookie()
Daarmee kan je meer, en hoef je ook niet in de headers te klooien

Canon EOS | DJI M2P
Fotoblog · Mijn werk aan jouw muur

maandag 20 mei 2002 01:15

Acties:

Verwijderd

Topicstarter

setcookie kan minder aangezien het sessie-cookies zijn en de cookies waarvan ik dus gebruik wil maken moeten op lange termijn kunnen functioneren...

maandag 20 mei 2002 01:16

Acties:

Verwijderd

Topicstarter

en wat kan ik daarmee meer eigenlijk tov een cookie via de header??? ik zie geen extra mogelijkheden

maandag 20 mei 2002 01:19

Acties:

tomato

code:

1	uid=$userid;

Wat doet dit in de eerste header

Lijkt me dus nogal duidelijk waarom deze niet werkt, het is geen geldige Set-Cookie header.

maandag 20 mei 2002 01:24

Acties:

tomato

Caesium: Setcookie kan minder aangezien het sessie-cookies zijn

Dat hoeft niet zo te zijn. Door geen 'expires' veld mee te geven wordt het een 'in-session cookie' (welke zo lang blijft bestaan als je wilt, zolang de browser niet gesloten wordt). Dit geldt bij het handmatig setten van cookies in een header, maar ook bij het gebruik van de setcookie() functie.

maandag 20 mei 2002 01:26

Acties:

tomato

Caesium:

code:

1	header("Set-Cookie: sessie=$hash; uid=$userid; expires=$datum GMT; path=/");

Misschien ben je in de war met manier waarop clients informatie over cookies terug sturen?
Daar gaan ze namelijk wel op een regel:

code:

1	Cookie: cookie1=waarde1; cookie2=waarde2

maandag 20 mei 2002 01:27

Acties:

Postman

Op maandag 20 mei 2002 01:15 schreef Caesium het volgende:
setcookie kan minder aangezien het sessie-cookies zijn en de cookies waarvan ik dus gebruik wil maken moeten op lange termijn kunnen functioneren...

Waar bezeer je dit op?
Met setcookie kun je ook een cookie maken die 1 jaar geldig is, zou dus niet weten wat jij voor een termijn in gedachte hebt (of wat voor functionaliteit jij wilt implementeren).

Edit: Tomato geeft min of meer dezelfde reactie (met uitleg). Was weer eens te laat met verzenden.

maandag 20 mei 2002 02:58

Acties:

SWINX

tomato: edit knop zit rechts boven aan een berichtje...

Mannen komen van Mars Tweakers, vrouwen van Venus Bokt

maandag 20 mei 2002 09:43

Acties:

Dennis

SWINX:
tomato: edit knop zit rechts boven aan een berichtje...

Waar iemand zich al niet druk over maakt

maandag 20 mei 2002 09:51

Acties:

Verwijderd

Topicstarter

setCookie is dus een sessioncookie als je daarbij opgeeft dat ie een jaar geldig is ("moet leven") dan moet je je browser ook een jaar open laten staan... als je via de header een cookie set dan blijft die bewaard ongeacht je computer uitzet...

maandag 20 mei 2002 09:59

Acties:

Verwijderd

Op maandag 20 mei 2002 09:51 schreef Caesium het volgende:
setCookie is dus een sessioncookie als je daarbij opgeeft dat ie een jaar geldig is ("moet leven") dan moet je je browser ook een jaar open laten staan... als je via de header een cookie set dan blijft die bewaard ongeacht je computer uitzet...

NIET!!!!

setcookie() defines a cookie to be sent along with the rest of the header information. Cookies must be sent before any other headers are sent (this is a restriction of cookies, not PHP). This requires you to place calls to this function before any <html> or <head> tags.

maandag 20 mei 2002 14:58

Acties:

Verwijderd

Topicstarter

Ik heb het met setcookie geprobeerd, echter ook met setcookie word alleen de laatste cookie geset! Wat o wat kan het probleem zijn? (PHP 4.2.0/Apache 2.0.36/FreeBSD 4.5-STABLE)

PHP:

<?error_reporting(E_ALL);setcookie ("cookie[three]", "cookiethree");setcookie ("cookie[two]", "cookietwo");setcookie ("cookie[one]", "cookieone");if (isset ($cookie)) {    while (list ($name, $value) = each ($cookie)) {        echo "$name == $value<br>\n";    }}?>

Output van php-script:

code:

1 2	one == cookieone TEST

maandag 20 mei 2002 15:28

Acties:

LuCarD

Certified BUFH

Op maandag 20 mei 2002 14:58 schreef Caesium het volgende:
Ik heb het met setcookie geprobeerd, echter ook met setcookie word alleen de laatste cookie geset! Wat o wat kan het probleem zijn? (PHP 4.2.0/Apache 2.0.36/FreeBSD 4.5-STABLE)

PHP4.2.0 in combinatie met Apache 2.0.36

Is om licht gezegt buggy...

Programmer - an organism that turns coffee into software.

maandag 20 mei 2002 15:31

Acties:

SWINX

Op maandag 20 mei 2002 14:58 schreef Caesium een stukje php

je kunt cookies toch niet op dezelfde pagina al gaan checken. Je moet eerst naar een andere pagina gaan oid.

[edit]

en wat is $cookie voor een variable

Mannen komen van Mars Tweakers, vrouwen van Venus Bokt

maandag 20 mei 2002 15:34

Acties:

Verwijderd

Topicstarter

Op maandag 20 mei 2002 15:31 schreef SWINX het volgende:

[..]

je kunt cookies toch niet op dezelfde pagina al gaan checken. Je moet eerst naar een andere pagina gaan oid.

euhm me opzet was simpel cookies setten op ctrl-r of f5 rammen en dan de output zien... lijkt me op zich logisch?

maandag 20 mei 2002 15:36

Acties:

Verwijderd

Topicstarter

Op maandag 20 mei 2002 15:28 schreef LuCarD het volgende:

[..]

PHP4.2.0 in combinatie met Apache 2.0.36

Is om licht gezegt buggy...

Ben nu naar PHP 4.2.0 aan het kijken en aan het updaten naar 4.2.1

Idd de link tussen PHP en Apache is buggy zoals ze het zeggen, de bestaande applicaties die ontwikkeld al waren op de server waarmee ik bezig ben werken perfect, echter cookies zo te zien niet... kijken wie de boosdoener is php of apache

maandag 20 mei 2002 15:39

Acties:

LuCarD

Certified BUFH

Op maandag 20 mei 2002 15:36 schreef Caesium het volgende:

[..]

Ben nu naar PHP 4.2.0 aan het kijken en aan het updaten naar 4.2.1

Idd de link tussen PHP en Apache is buggy zoals ze het zeggen, de bestaande applicaties die ontwikkeld al waren op de server waarmee ik bezig ben werken perfect, echter cookies zo te zien niet... kijken wie de boosdoener is php of apache

Helaas ik moet je teleur stellen ook 4.2.1 is nog buggy met Apache 2.

Verwacht wordt dat versie 4.3 pas stabiel is met Apache 2

De boosdoener is IMHO php.

Programmer - an organism that turns coffee into software.

maandag 20 mei 2002 15:43

Acties:

T.T.

Sowieso

volgens mij moet je gewoon eens goed gaan lezen wat cookies nou eigenlijk zijn. Aan al je foute veronderstellingen te zien snap je er niets van, en dan wordt programmeren wel erg moeilijk....

Als je met sessies werkt, dan moet je maar eens kijken naar session_start() (die zet zelf al een cookie, waar je dus ook de levensduur van kan aanpassen).
UserID lijkt me onzin om ook nog in cookie te zetten als je al een sessie hebt...

maandag 20 mei 2002 16:09

Acties:

Verwijderd

Topicstarter

Op maandag 20 mei 2002 15:43 schreef T.T. het volgende:
volgens mij moet je gewoon eens goed gaan lezen wat cookies nou eigenlijk zijn. Aan al je foute veronderstellingen te zien snap je er niets van, en dan wordt programmeren wel erg moeilijk....

Als je met sessies werkt, dan moet je maar eens kijken naar session_start() (die zet zelf al een cookie, waar je dus ook de levensduur van kan aanpassen).
UserID lijkt me onzin om ook nog in cookie te zetten als je al een sessie hebt...

Lol, ik denk dat jij het niet weet waar je het over hebt oid

Sessions en Cookies zijn 2 totaal aparte dingen

en als je helemaal al weinig van beveiliging af weet gaan me dan niet de les proberen voor te schrijven want van dat soort mensen ga ik dus echt over me [overbodig] als je me wilt verbeteren verbeter me dan zodanig dat ik er a) wat van leer en b) niet op het verkeerde spoor word gezet! Wil je al mijn foute veronderstellingen even neerzetten en beargumenteren dan als ze allemaal fout zijn?

Op maandag 20 mei 2002 15:39 schreef LuCarD het volgende:

[..]

Helaas ik moet je teleur stellen ook 4.2.1 is nog buggy met Apache 2.

Verwacht wordt dat versie 4.3 pas stabiel is met Apache 2

De boosdoener is IMHO php.

De boosdoener in dit geval was Apache 2

Zo te zien maakt Apache 2 een zooitje van headers... of PHP parsed de headers niet goed of het "formaat" wat door Apache heen gaat aan headers is totaal veranderd en in PHP niet... Me oplossing nu is dus Apache 1.3.24 en PHP 4.2.1.. tnx iig allemaal voor jullie hulp...

[overbodige smilie verwijderd, ACM]

maandag 20 mei 2002 16:15

Acties:

LuCarD

Certified BUFH

Op maandag 20 mei 2002 16:09 schreef Caesium het volgende:

De boosdoener in dit geval was Apache 2 Zo te zien maakt Apache 2 een zooitje van headers... of PHP parsed de headers niet goed of het "formaat" wat door Apache heen gaat aan headers is totaal veranderd en in PHP niet... Me oplossing nu is dus Apache 1.3.24 en PHP 4.2.1.. tnx iig allemaal voor jullie hulp...

Ik denk niet dat er 1 echt aan te wijzen is als boosdoener... Aangezien 1 zonder de andere goed werkt. Dit geldt zowel voor PHP als Apache. Maar aangezien Apache een verandering heeft gemaakt voor de benadering van modules, waar PHP 1 van is. Ben ik van mening dat PHP de foute is. Ook binnen het PHP Dev group zijn ze hard bezig om PHP goed te laten werken met Apache 2. Maar helaas laat dat nog even op zich wachten.

Programmer - an organism that turns coffee into software.

maandag 20 mei 2002 16:17

Acties:

ACM

Software Architect

Werkt hier

Op maandag 20 mei 2002 16:09 schreef Caesium het volgende:
Lol, ik denk dat jij het niet weet waar je het over hebt oid Sessions en Cookies zijn 2 totaal aparte dingen

Zo "totaal" verschillen ze bij php niet eens

Bij Servlets kan je ze wat nuttiger 'totaal' laten verschillen, maar behalve dat de sessie serverside en de cookie clientside is... (ok, wel heel belangrijk verschil).

Verder vraag ik me ook af waarom je een sessie-id EN een userid nodig hebt als cookie's.
Sterker nog, daarmee geef je sessie-kapers een heel handig houvast als je toevallig 'userid based' de rechten op je site uitdeelt.

en als je helemaal al weinig van beveiliging af weet gaan me dan niet de les proberen voor te schrijven want van dat soort mensen ga ik dus echt over me [overbodig]

Die smilie vond ik _nogal_ overbodig.

Alle aangeboden hulp zou je minimaal met een glimlach moeten ontvangen. Dat bij de ene keer (goede hulp) de glimlach echt is en de andere keer (slechte hulp, of niet goed lijkend, etc) de glimlach nep is boeit niet.

als je me wilt verbeteren verbeter me dan zodanig dat ik er a) wat van leer en b) niet op het verkeerde spoor word gezet! Wil je al mijn foute veronderstellingen even neerzetten en beargumenteren dan als ze allemaal fout zijn?

Verkeerd spoor?

maandag 20 mei 2002 16:17

Acties:

SWINX

try dit eens:

cookie.php

PHP:

1	<?setcookie("koekje1","inhoudvankoekje1",time()+3600);setcookie("koekje2","inhoudvankoekje2",time()+3600);setcookie("koekje3","inhoudvankoekje3",time()+3600);header("Location: cookie2.php");?>

cookie2.php

PHP:

1	<?echo $_COOKIE["koekje1"];echo $_COOKIE["koekje2"];echo $_COOKIE["koekje3"];?>

Mannen komen van Mars Tweakers, vrouwen van Venus Bokt

maandag 20 mei 2002 16:28

Acties:

Verwijderd

Topicstarter

Op maandag 20 mei 2002 16:17 schreef ACM het volgende:
Zo "totaal" verschillen ze bij php niet eens
Bij Servlets kan je ze wat nuttiger 'totaal' laten verschillen, maar behalve dat de sessie serverside en de cookie clientside is... (ok, wel heel belangrijk verschil).
Verder vraag ik me ook af waarom je een sessie-id EN een userid nodig hebt als cookie's.
Sterker nog, daarmee geef je sessie-kapers een heel handig houvast als je toevallig 'userid based' de rechten op je site uitdeelt.

Een aardig groot verschil vind ik zelf cookies = client-side en sessions = server-side waar de inhoud wordt opgeslagen... en SESSIONS zoals het al zegt is echt een sessie in een browser zodra de browser is afgesloten dan is er geen sessie meer en moet je opnieuw inloggen...

Waarom ik user-id's uitdeel is heel simpel:
De client heeft een sessie-id (hash) en user-id
eerst wordt de sessie-id (hash) gecontroleerd bestaat de sessie-id (hash) dan wordt de user-id gecontroleerd of die overeenkomt met de user_id die ingelogd is met die al gecontroleerde sessie-id (hash), zo niet dan wordt de sessie met bijbehorende sessie-id getrashed zodat er geen misbruik van gemaakt kan worden mocht er iemand een "systeem in hoe de hashes worden gemaakt (het is random maar wat is random he? :)" of een sessie-id (hash) gevonden heb dan kan hij/zij nog geen misbruik er van maken omdat hij/zij ook nog een user-id daarbij nodig heeft en kan vervolgens maar 1 keer gokken of die goed is anders wordt die sessie weggegooid

en pas als beiden kloppen zoals in bovenstaand verhaal beschreven staat worden de rechten vrijgegeven voor die pagina... (en zoals ik had begrepen werkt dit systeem ook op tweakers.net)...

Op maandag 20 mei 2002 16:17 schreef SWINX het volgende:
try dit eens:

cookie.php
PHP:
1
<? blalalal ?>

Was niet nodig het probleem zat hem in de combinatie PHP met Apache 2

opgelost met oudere versie van Apache 1.3.24

maandag 20 mei 2002 16:44

Acties:

Verwijderd

sessions en cookies liggen dichter bij elkaar dan je denkt. sessions maken ook gebruik van cookies, nl. om de session_id in op te slaan. De werkelijke data wordt wel server-side opgeslagen. Verder kun je sessions ook een langere lifetime geven, en dus als 'server-side-cookies' gebruiken. Met enige aanpassingen is het enige verschil dus dat de data op de server wordt opgeslagen. Cookies worden er sowieso geplaatst...

maandag 20 mei 2002 16:54

Acties:

Verwijderd

Topicstarter

Ik vind er zelf veel gevaren zitten aan een session....

- De sessionhashes zijn niet zo random blijkt uit een simpel testje van mij binnen 1 uur had ik al 2 dezelfde

- Als je zo makkelijk een sessionhash te pakken hebt heb je ook al de corresponderende data natuurlijk waarin ook de user-id en bij de meeste rechten zitten toegewezen dit was zelfs zo een tijdje terug bij phpnuke ik hoop dat dit inmiddels is opgelost door een extra cookie te sturen...

- En een cookie die geset wordt voor een SESSION is zo te merken een sessie-cookie dus als de browser afgesloten word is de sessie-cookie weg, terwijl de SESSION die is opgeslagen nog eventueel aanwezig kan zijn...

- Je kan bij een eigen tabel (database) met sessies erin controleren of iemand actief is geweest het laatste uur zo niet dan trashen de boel... bij een session kan je wel is waar een max-lifetime meegeven maar die moet langer zijn dan bijv een uur en als je dan wilt dat als de user een half uur niks heeft gedaan de sessie wordt verwijderd dan is dat een probleem ... als je de maxlifetime aanpast dan kan de user "maar" een half uur ingelogd zijn tenzij je iedere keer nieuwe sessions om de zo veel tijd gaat aanmaken voor die user en alles over zet wat niet zo efficient is natuurlijk

maandag 20 mei 2002 17:08

Acties:

LuCarD

Certified BUFH

Op maandag 20 mei 2002 16:54 schreef Caesium het volgende:
Ik vind er zelf veel gevaren zitten aan een session....

- De sessionhashes zijn niet zo random blijkt uit een simpel testje van mij binnen 1 uur had ik al 2 dezelfde

Maak je eigen betere sessionid zou ik zeggen
http://nl.php.net/manual/nl/function.session-id.php

- Als je zo makkelijk een sessionhash te pakken hebt heb je ook al de corresponderende data natuurlijk waarin ook de user-id en bij de meeste rechten zitten toegewezen dit was zelfs zo een tijdje terug bij phpnuke ik hoop dat dit inmiddels is opgelost door een extra cookie te sturen...

Sla in je session id een extra hoeveelheid gegevens op die gebruiker unieker maakt.
bv.
- IP (F**k AOL, en mensen die een multi-ip NAT gebruiken

)
- Browser Agent
- Scherm Resolutie (dmv JavaScript)
- Een tweede Cookie, zoals jij al zei..

- En een cookie die geset wordt voor een SESSION is zo te merken een sessie-cookie dus als de browser afgesloten word is de sessie-cookie weg, terwijl de SESSION die is opgeslagen nog eventueel aanwezig kan zijn...

Zelfde punt boven

- Je kan bij een eigen tabel (database) met sessies erin controleren of iemand actief is geweest het laatste uur zo niet dan trashen de boel... bij een session kan je wel is waar een max-lifetime meegeven maar die moet langer zijn dan bijv een uur en als je dan wilt dat als de user een half uur niks heeft gedaan de sessie wordt verwijderd dan is dat een probleem ... als je de maxlifetime aanpast dan kan de user "maar" een half uur ingelogd zijn tenzij je iedere keer nieuwe sessions om de zo veel tijd gaat aanmaken voor die user en alles over zet wat niet zo efficient is natuurlijk

Je kan de laatste activiteit toch opslaan bij de user. Dus op elke pagina een update naar de db gooien. Van waar hij is.

En dan Sessions trashen na een half uur na de laatste activiteit.

Programmer - an organism that turns coffee into software.

maandag 20 mei 2002 19:48

Acties:

T.T.

Sowieso

Sessions en Cookies zijn 2 totaal aparte dingen

Ehmm, waar zeg ik precies dat het dezelfde dingen zijn??
Volgens mij helemaal nergens, dat maak jij ervan?

maar ff op je reactie:

setCookie is dus een sessioncookie als je daarbij opgeeft dat ie een jaar geldig is ("moet leven") dan moet je je browser ook een jaar open laten staan

Dat is dus onzin, zoals zellufs al opmerkte.

setcookie kan minder aangezien het sessie-cookies zijn en de cookies waarvan ik dus gebruik wil maken moeten op lange termijn kunnen functioneren

Lijkt me ook niet zondermeer waar, zoals tomato ook opmerkte.

zo niet dan wordt de sessie met bijbehorende sessie-id getrashed zodat er geen misbruik van gemaakt kan worden mocht er iemand een "systeem in hoe de hashes worden gemaakt

Kijk, dat is nou een goede reden. In plaats van dat je dat even replied op mijn opmerking dat het me niet nuttig leek, ga je lopen flamen als iemand kritiek op je heeft (met reden de bovenstaande quotes)??

maandag 20 mei 2002 20:36

Acties:

Verwijderd

Topicstarter

ik heb nu alles geprobeerd met setCookie maar bij mij slaat hij die cookie dus echt niet op! en als ik via de headers een cookie stuur wel... daarop baseer ik het feit dat setcookie minder kan dan via de headers... echter setcookie heeft de mogelijkheid voor met het secure gebeuren maar dat is mijn geval overbodig...

sessions en cookies vind ik nog steeds veel van elkaar schelen zo is het dat je bij cookies per variabele een tijdsduur er aan kan geven en wat LuCaRdo ofzo zei en session en db opslaan om daar aan te zien of die overbodig is vind ik niet echt bepaald efficient 2 x iets opslaan niet een beetje overbodig oid???

Sla in je session id een extra hoeveelheid gegevens op die gebruiker unieker maakt.
bv.
- IP (F**k AOL, en mensen die een multi-ip NAT gebruiken )
- Browser Agent
- Scherm Resolutie (dmv JavaScript)
- Een tweede Cookie, zoals jij al zei..
quote:
--------------------------------------------------------------------------------
- En een cookie die geset wordt voor een SESSION is zo te merken een sessie-cookie dus als de browser afgesloten word is de sessie-cookie weg, terwijl de SESSION die is opgeslagen nog eventueel aanwezig kan zijn...
--------------------------------------------------------------------------------

Zelfde punt boven

IP kan je niet doen neem een voorbeeld aan mensen die gebruik maken van een proxy server kan iedere keer een andere IP hebben neem een voorbeeld aan de proxy van casema.. JavaScript is een gammel scripttooltje wat mensen uit kunnen hebben staan moet je ze dan meteen een middelvinder toe heffen van jij hebt lekker pech? geen nette oplossing lijkt me... ook browser agent hoeft niet door elke browser te worden afgegeven neem maar een voorbeeld aan wap-telefoons en op palmtops... en nogmaals mij is het niet gelukt om een session-cookie of een setcookie op te laten slaan bij die client zodra ik de browser af had gesloten was de cookie ook weg...

maandag 20 mei 2002 20:58

Acties:

martinvw

ook browser agent hoeft niet door elke browser te worden afgegeven neem maar een voorbeeld aan wap-telefoons en op palmtops...

Mijn telefoon geeft ook een user_agent af dus ik vermoed dat alle aparaten dat zullen doen mijn siemens C35 bv:
[HTTP_USER_AGENT] => SIE-C3I/3.0 UP/4.1.16m

Dus die zou je wel goed kunnen gebruiken.

maandag 20 mei 2002 22:05

Acties:

wietco

Misschien een domme opmerking hoor maar waarom set je voor elke var een eigen cookie?

PHP:

<?$cookiedata = Array("sessie" => $hash,"userid" => $userid);setcookie("testcookie",serialize($cookiedata),time()+3600);// data terughalen$data = unserialize($HTTP_COOKIE_VARS['testcookie']);echo $data['sessie'];echo $data['userid']; ?>

zo doe ik het altijd

dinsdag 21 mei 2002 02:06

Acties:

WouZz

Elvis is alive!

De client heeft een sessie-id (hash) en user-id
eerst wordt de sessie-id (hash) gecontroleerd bestaat de sessie-id (hash) dan wordt de user-id gecontroleerd of die overeenkomt met de user_id die ingelogd is met die al gecontroleerde sessie-id (hash), zo niet dan wordt de sessie met bijbehorende sessie-id getrashed zodat er geen misbruik van gemaakt kan worden mocht er iemand een "systeem in hoe de hashes worden gemaakt (het is random maar wat is random he? " of een sessie-id (hash) gevonden heb dan kan hij/zij nog geen misbruik er van maken omdat hij/zij ook nog een user-id daarbij nodig heeft en kan vervolgens maar 1 keer gokken of die goed is anders wordt die sessie weggegooid

In principe moet een sessie-id niet 'te raden zijn'. Met een gewone md5 hash kan je 36³² = 6,334028666⁴⁹ verschillende sessie's maken, dus die 'raad' je niet zo makkelijk... Als je bang bent dat mensen 'brute-force' sessie-id gaan uitproberen, lijkt het me 'veilig' om dat soort clients voor (on)bepaalde duur te bannen/blocken.

Als je bang bent dat iemand aan een geldige sessie-id kan komen via een packetsniffer ofzoow, dan lijkt het me ook niet zo moeilijk om de bijbehorende user-id uit de header te vissen... Dit kan je alleen voorkomen door het gebruik van SSL. Wil je toch per se het user-id meesturen voor controle, dan lijkt het me raadzaam om deze ook nog even te hashen, hoewel het kraken van een user-id natuurlijk wel heel erg makkelijk is. Dit kan je weer lastiger maken door een hash van de user-id + lekkerlanggeheimwachtwoord mee te sturen. Nadeel hiervan is dat als dit lekkerlanggeheimwachtwoord bekend wordt, meteen alle user-id's weer makkelijk te kraken zijn uit de hashes. Of gebruik iets unieks zoals LuCarD al zei.

ik heb nu alles geprobeerd met setCookie maar bij mij slaat hij die cookie dus echt niet op! en als ik via de headers een cookie stuur wel... daarop baseer ik het feit dat setcookie minder kan dan via de headers... echter setcookie heeft de mogelijkheid voor met het secure gebeuren maar dat is mijn geval overbodig...

sessions en cookies vind ik nog steeds veel van elkaar schelen zo is het dat je bij cookies per variabele een tijdsduur er aan kan geven en wat LuCaRdo ofzo zei en session en db opslaan om daar aan te zien of die overbodig is vind ik niet echt bepaald efficient 2 x iets opslaan niet een beetje overbodig oid???

Sessions en cookies zijn ook andere 'dingen'. Sterker nog: sessions kunnen gebruik maken van cookies. Het idee van sessions is dat je op de client alleen een uniek id 'opslaat', in de vorm van een cookie of GET variabele zodat de client zich hiermee kan identificeren aan de server waar de bijbehorende data is opgeslagen. En of je nou sessions, setcookie() of header() gebruikt, uiteindelijk wordt er toch wel een Set-cookie: header meegestuurd. Voordeel van setcookie() is dat PHP de juiste syntax voor je regelt. En gezien het huidige aantal setcookie()-gebruikers op het web, denk ik niet dat die niet goed werkt..

On track

dinsdag 21 mei 2002 02:36

Acties:

Soultaker

En (groot) extra stuk beveiliging kan al verkregen worden door het IP adres van de verzender op te slaan bij het initialiseren van je sessie. Door nu elke keer dit adres met het adres van de client te vergelijken, kun je je er in ieder geval van verzekeren dat je elke keer met dezelfde computer praat. Dit werkt natuurlijk alleen zolang je kan garanderen dat een client altijd hetzelfde IP heeft en geen andere client dat IP kan gebruiken.

De enige 'goede' oplossing is natuurlijk het gebruik van SSL.

dinsdag 21 mei 2002 02:43

Acties:

WouZz

Elvis is alive!

Op dinsdag 21 mei 2002 02:36 schreef Soultaker het volgende:
De enige 'goede' oplossing is natuurlijk het gebruik van SSL.

Helemaal mee eens! Packets zijn te sniffen, IP's zijn te spoofen... De vraag is aan jou of je je systeem daartegen wilt beveiligen...

On track

dinsdag 21 mei 2002 12:13

Acties:

Verwijderd

Topicstarter

Op dinsdag 21 mei 2002 02:36 schreef Soultaker het volgende:
En (groot) extra stuk beveiliging kan al verkregen worden door het IP adres van de verzender op te slaan bij het initialiseren van je sessie. Door nu elke keer dit adres met het adres van de client te vergelijken, kun je je er in ieder geval van verzekeren dat je elke keer met dezelfde computer praat. Dit werkt natuurlijk alleen zolang je kan garanderen dat een client altijd hetzelfde IP heeft en geen andere client dat IP kan gebruiken.

De enige 'goede' oplossing is natuurlijk het gebruik van SSL.

SSL is onder andere een optie dat hebben we dus ook deels draaien echter via WAP werkt SSL nog niet echt, terwijl het wel mogelijk deels moet zijn (maar daarvoor moet ik nog even verder kijken...

Wat ik over het IP gebeuren zei geld nu nog steeds als een gebruiker via een proxy op internet zit bijv die van casema hebben ze geen vast IP (zelfs de proxy server niet) aangezien de proxy verdeelt is over meerdere machines zijn er ook meerdere IPs we hebben het getest en hadden in 1 sessie met het intranet 3 verschillende IP's te pakken weliswaar in dezelfde range maar toch...

Op maandag 20 mei 2002 22:05 schreef wietco het volgende:
Misschien een domme opmerking hoor maar waarom set je voor elke var een eigen cookie?
PHP:
1
<? echo "stukje php"; ?>
zo doe ik het altijd

Omdat ik nu de userid cookie hebben weggehaald en er nu iedere keer als de gebruiker op een andere pagina komt een andere hash toegewezen krijgt... en als ik dat totaal iedere keer serialize is het effect deels van veiligheid want dan had ik net zo goed alleen een cookie kunnen sturen...

maar tnx voor je idee

Op maandag 20 mei 2002 20:58 schreef M4rt1nvW het volgende:

[..]

Mijn telefoon geeft ook een user_agent af dus ik vermoed dat alle aparaten dat zullen doen mijn siemens C35 bv:
[HTTP_USER_AGENT] => SIE-C3I/3.0 UP/4.1.16m

Dus die zou je wel goed kunnen gebruiken.

me lite-browser op me palmtop gaf naar mijn weten geen USER_AGENT af en me samsung telefoon iets heel wazigs dus zit ik met een probleem hoe lang moet je dan die variabele maken waar die user agent in gaat (hmm ik kan natuurlijk de string afkappen en bijv 32 chars pakken...)

dinsdag 28 mei 2002 22:03

Acties:

Verwijderd

code:

$letters = array ("0","1"...);
$sess="";
for ($i=0;$i<32;$i++){
  $sess.= $letters[rand(0,count($letters))];
}

print "sessie: ".$sess;

iets met user-browser ed hoeft niet

PHP Doc verteld op deze pagina het volgende:
In older versions of PHP, you had to seed the random number generator before use with mt_srand(). Since 4.2.0 this is no longer necessary.

donderdag 30 mei 2002 13:14

Acties:

Verwijderd

met PHP 4.2.1 ontstaan die cookie problemen, probeer te upgraden naar PHP 4.3.0 (-dev) (download: snaps.php.net). Daarin werkt alles weer.

Pagina: 1

Reageer