[PHP 5.x] Cookie probleem

[Verwijderd]

Beste devvers,

Ik ben verantwoordelijk voor een eCommerce product bij het bedrijf waar ik werkt. Dit systeem is geschreven in PHP en wordt op een Win2k3 server (IIS, Plesk) gehost.

Sinds onze software steeds vaker gebruikt wordt lijkt er bij 1 op de 100 klanten een probleem te zijn met inloggen. Het systeem gebruikt gewoon de standaard session functionaliteit uit PHP. Als mensen ingelogd zijn blijken ze spontaan weer uitgelogd en het lijkt er daarmee op dat de cookie niet geaccepteerd wordt en de sessie zo niet gehandhaafd blijft.

Nu ben ik bezig het e.a. om te schrijven om te zorgen SESID danwel via POST/GET meegegeven wordt met alle nadelen voor de eerst gebruikersvriendelijke URL's!

Wat ik me nu af vroeg, hoe kan het dat de browsers van die mensen geen cookies accepteren? Deze mensen zijn er kennelijk niet van op de hoogte. (Het is not done om de klanten van je klanten te ondervragen ihmo ) maar ik kan deze situatie alleen creëren als ik cookies bewust weiger.... 1 op de 100 mensen weigert ze zonder daarvan op de hoogte te zijn?

Hebben jullie soortgelijke ervaringen of hebben jullie altijd met automagisch herschreven URL's gewerkt (bv session.use_trans_sid) als er een cookie probleem is?

[Scharnout]

* Scharnout heeft ook eCommerce siteje.

Veel bedrijven (en ja iedereen shopt op het internet op zijn werk ) hebben standaard dat soort dingen uit staan. Ik krijg ook wel eens klachten en meestal is dat uiteindelijk het probleem. Een oplossing heb ik niet voor je, want ik werk net met php. Ik zag wel andere rare dingen, zoals pagina's die niet meer gecached worden als je een session_start() doet. Dat hele sessieverhaal vind ik nog wat vaag in php.

[iH8]

Verwijderd schreef op dinsdag 29 juli 2008 @ 08:44:

Nu ben ik bezig het e.a. om te schrijven om te zorgen SESID danwel via POST/GET meegegeven wordt met alle nadelen voor de eerst gebruikersvriendelijke URL's!

dat is dan toch echt niet je grootste nadeel. ik zou me zorgen maken over m'n security. zeker aangezien je praat over een eCommerce-applicatie.

[Verwijderd]

Meeste van onze klanten leveren ook aan bedrijven. Dit zijn meestal het soort gebruikers die je feedback geven en daar is het probleem dan ook gemakkelijk op te lossen door een systeembeheerder die rond loopt.

Toch zijn er ook particulieren waar het mis gaat... Dat is waar ik me zorgen over maak. Maar wat zou nou de oorzaak zijn dat die cookies daar niet aankomen? Uit de enkele gevallen waar ik feedback kon krijgen kon ik afleiden dat ze vaak niet eens weten wat cookies zijn, laat staan hoe ze te weigeren!

Nu is het op internet zo dat als het niet werkt mensen vaak gewoon naar de concurrent gaan en daar hoor je verder niks meer van. Die 1 op de 100 mensen die een mailtje sturen voor ondersteuning kunnen slechts een fractie van de groep met problemen zijn.

iH8 schreef op dinsdag 29 juli 2008 @ 08:55:
[...]
dat is dan toch echt niet je grootste nadeel. ik zou me zorgen maken over m'n security. zeker aangezien je praat over een eCommerce-applicatie.

Dat komt wel goed. Het brengt veel nadelen met zich mee, maar of je nou met cookies, post of get werkt het sessid wordt altijd gewoon verzonden (ex. https).

[ Voor 21% gewijzigd door Verwijderd op 29-07-2008 09:02 ]

[TeeDee]

• zet je sessionid in een hidden field en lees deze uit (desnoods nog voor de schijnveiligheid met gebruikmaking van een md5 eroverheen)
• komen er ook mensen via een iframe op de ecommerce site?
• maak een 'landingspagina', zet daar een testcookie, kijk of je deze uit kan lezen. Zo niet: melding geven (en daarna is het 'out of your hands'). Je kan ze hoogstens nog een help, url of wat dan ook aanbieden over hoe ze cookies aan moeten zetten.

[Verwijderd]

TeeDee schreef op dinsdag 29 juli 2008 @ 09:06:
• zet je sessionid in een hidden field en lees deze uit (desnoods nog voor de schijnveiligheid met gebruikmaking van een md5 eroverheen)
• komen er ook mensen via een iframe op de ecommerce site?
• maak een 'landingspagina', zet daar een testcookie, kijk of je deze uit kan lezen. Zo niet: melding geven (en daarna is het 'out of your hands'). Je kan ze hoogstens nog een help, url of wat dan ook aanbieden over hoe ze cookies aan moeten zetten.

- Handige tip
- iFrame issue is mij bekend en geen probleem.
- Soortgelijke functionaliteit wordt getest na het inloggen... Enkel als je niet weet wat cookies zijn is het moeilijk om ze aan te zetten en de gemiddelde gebruiker gaat zich absoluut de moeite niet doen.

[TheRookie]

Er staat me ook bij dat er een limiet is aan het aantal /grootte van cookies dat per site weggeschreven mag worden; iirc had tweakers hier op een gegeven moment last van met als resultaat het 'cookiemonster'

[Cartman!]

Je sessionid via post/get overhevelen van pagina tot pagina lijkt me geen goed idee. Lees je eens in op session hijacking en session fixation.Even iemand een linkje sturen naar een vriend zorgt ervoor dat ie direct ingelogd kan zijn onder jouw accouny. Als je klant ervoor kiest dat ie geen cookies accepteert dan is dat eigenlijk hun probleem (daar lijkt het gewoon op namelijk).

[Verwijderd]

Cartman! schreef op dinsdag 29 juli 2008 @ 09:13:
Je sessionid via post/get overhevelen van pagina tot pagina lijkt me geen goed idee. Lees je eens in op session hijacking en session fixation.Even iemand een linkje sturen naar een vriend zorgt ervoor dat ie direct ingelogd kan zijn onder jouw accouny. Als je klant ervoor kiest dat ie geen cookies accepteert dan is dat eigenlijk hun probleem (daar lijkt het gewoon op namelijk).

Je moet wel erg stom zijn om enkel op SESSID een sessie te identificeren/accepteren ;-).

Voorbeeld, zit je nu op mijn bol account?

[Confusion]

Verwijderd schreef op dinsdag 29 juli 2008 @ 09:15:
Je moet wel erg stom zijn om enkel op SESSID een sessie te identificeren/accepteren ;-).

Koppelen aan IP maakt het niet veel veiliger. Alle andere variabelen zijn net zo onderschepbaar als het session ID en helpen dus niet. Uiteindelijk blijft het gewoon lek; je moet naar de constructies die banken toepassen om het echt veilig te krijgen. De vraag is waar je genoegen mee neemt en voor de meeste toepassingen, inclusief webshops, is een session ID voldoende.

(Wat Bol.com doet, om de haverklap mijn wachtwoord opnieuw vragen, vind ik rammend irritant. Laat me dan liever telkens mijn cc of bankrekeningnummer opnieuw invoeren als ik een bestelling doe.)

Hieronder:
Ook cookies kun je onderscheppen!

Ja, die vat ik onder 'andere variabelen'.

[ Voor 46% gewijzigd door Confusion op 29-07-2008 09:29 ]

[Verwijderd]

Confusion schreef op dinsdag 29 juli 2008 @ 09:24:
[...]

Koppelen aan IP maakt het niet veel veiliger. Alle andere variabelen zijn net zo onderschepbaar als het session ID en helpen dus niet.

Ook cookies kun je onderscheppen!

De nadelen wegen momenteel helaas op tegen de voordelen. Ik kan mijn baas niet vertellen dat er een mailtje gestuurd moet worden naar alle klanten met de melding dat als mensen niet kunnen inloggen ze maar bij de concurrent moeten shoppen .

TheRookie schreef op dinsdag 29 juli 2008 @ 09:11:
Er staat me ook bij dat er een limiet is aan het aantal /grootte van cookies dat per site weggeschreven mag worden; iirc had tweakers hier op een gegeven moment last van met als resultaat het 'cookiemonster'

Hmm, ik gebruik enkel 1 cookie. De rest is server-side.

[ Voor 29% gewijzigd door Verwijderd op 29-07-2008 09:27 ]

[TeeDee]

Tja, mensen die op wat voor manier (hetzij policy (wat doe je dan shoppend tijdens je werk) of paranoia of of of) dan ook zonder cookie browsen kunnen niet verwachten dat de huidige webshops nog normaal functioneren.

Ik kan je alleen adviseren: kijk eens naar amazon, bol of weet ik veel wat in hun help, support.

[Cartman!]

Verwijderd schreef op dinsdag 29 juli 2008 @ 09:15:
[...]


Je moet wel erg stom zijn om enkel op SESSID een sessie te identificeren/accepteren ;-).

Voorbeeld, zit je nu op mijn bol account?

Ik ga er voor t gemak even vanuit dat de TS niet dezelfde software gebruikt als bol.com. Ik vraag me af of de TS ook een ip check had ingebakken. Enneh... als je met 500 man in een pand zit en 1 ip adres deelt, dan maakt die ip check t niet veiliger hoor. Dan ben je nog steeds ingelogd na het sturen van je linkje voor dat leuke product. IP adressen nooit vertrouwen imo.

Als je in 2008 zonder cookies wil werken dan is dat het probleem van de gebruiker vind ik, hoe kun je anders verwachten ingelogd te blijven op een (redelijk) veilige manier.

[Scharnout]

Cartman! schreef op dinsdag 29 juli 2008 @ 10:02:
[...]
Als je in 2008 zonder cookies wil werken dan is dat het probleem van de gebruiker vind ik, hoe kun je anders verwachten ingelogd te blijven op een (redelijk) veilige manier.

En dan te bedenken dat ze de cookies wilden verbieden een paar jaar geleden ...

[ Voor 33% gewijzigd door Scharnout op 29-07-2008 10:14 ]

[Creepy]

Zijn die mensen direct uitgelogd of na een paar minuten? We hebben hier al regelmatig meegemaakt dat de sessie verloren gaat als de gebruiker geen interactie heeft gehad met de server voor een kwartier. Eén of andere firewall die er tussen zit zorgt er dan voor dat er qua cookies helemaal niks meer meekomt. Ook hebben we regelmatig gezien dat als een request naar de server toe groter is dan 64KB er firewalls zijn die dat ook maar gewoon blocken en dan ook direct alle cookies e.d. tegenhoudt zodat ook de sessie is verdwenen. (Ok, dit gaat over een andere applicatie, maar toch..)

[Cartman!]

Na inactiviteit kan je sessie serverside verwijderd worden, deze instelling wisselt per server. Daarom gebruik ik ook een eigen sessionhandler (ongeveer gelijk aan hier op GoT) om daar geen last van te hebben. Uit zn tekst maak ik op dat mensen eigenlijk direct weer uitgelogd zijn, vandaar de cookie discussie

[BBrunekreeft]

Creepy schreef op dinsdag 29 juli 2008 @ 10:24:
Zijn die mensen direct uitgelogd of na een paar minuten? We hebben hier al regelmatig meegemaakt dat de sessie verloren gaat als de gebruiker geen interactie heeft gehad met de server voor een kwartier.

Standaard staat er in php.ini een wat krappe maxlifetime voor sessions:
session.gc_maxlifetime = 1440 (is 24 minuten)

in .htaccess kun je dat eventueel verhogen met

php_value session.gc_maxlifetime 86400

[TeeDee]

Creepy duidt op een issue buiten de lifetime van PHP om. Firewall (en sommige proxy, isa) configuraties willen wel eens alles laten vallen, ook al heb je een timeout van 3 jaar (bijv.)

[XiniX88]

Ok dan kan je wel de maxlifetime setten, maar dan kan dus de cookie weer verlopen

PHP:

$expireTime = 60*60*5;  // Set expiretime to 5 hours
session_set_cookie_params($expireTime, "/", "domain.com");
ini_set("session.gc_maxlifetime", $expireTime);
session_start();

ini_set werkt niet altijd, maar aangezien jullie de server beheren, zou dit wel moeten mogen. Anders kun je zoals BBrunekreeft voorsteld dit ook via .htaccess bewerkstelligen.

met session_set_cookie_params, zorg je er voor dat de cookie alleen werkt op "domain.com" en in het path "/" en hoger, ook verhoog je de timeout van het cookie.

Dit bij elkaar zou er hopelijk voor moeten zorgen dat klanten niet zomaar worden uitgelogd, en anders accepteren ze gewoon geen cookies.

[Verwijderd]

Lifetime is geen probleem. De sessie komt nooit op gang.
Ik gebruik o.a. een IP check. Echter nooit problemen mee gehad.

Session.use_trans_sid lijkt zijn werk goed te doen, vind het toch nog altijd geen prettige oplossing.

Sommige klanten zijn overgestapt van osCommerce waar ze nooit 'cookie' problemen hadden onder hun klanten. Dan kun je het niet maken om te zeggen 'probleem van de klant want anno 2008 moet iedereen zijn cookies op orde hebben' .

[Scharnout]

Even een kleine aanvulling. Google eens op p3p header. Dit lostte bij mij het probleem op. Sommige klanten kwamen van een andere site namelijk, dan ook nog eens in een iframe en dan lossten die p3p headers het eea op

[ Voor 41% gewijzigd door Scharnout op 15-09-2008 22:50 ]

[igmar]

De meest voorkomende issue zijn shops met meerdere URL's op 1 vhost. In Apache is dat de beroemde 'ServerAlias' regel.

Over het algemeen checkt de site of je ingelogd bent, en redirect je naar een nieuwe URL. Stel een situatie voor met 2 hostnames :

www.bla-bla.nl
www.blabla.nl

De ServerName = bla-bla.nl, maar je klant komt binnen op blabla.nl. Jouw code zal vervolgens na het inloggen redirecten naar www.bla-bla.nl/nieuwurl/

IE zal in z'n geval de cookies blokkkeren. Firefox doet dat niet. Ik los het zelf op door te kijken waar ze op binnenkomen, en ze direct te redirecten naar www.bla-bla.nl. De nette oplossing is dus om je redirect goed te doen.