[PHP] Altermatief voor sessie's

[anoniem]

Ik heb een online winkel ontwikkeld, waarbij de producten die in het 'winkelwagentje' zitten opgeslagen worden in een tijdelijke MySQL tabel, met als herkenning een User ID (UID) PHP houdt dit UID vast met behulp van Sessies (Sessions) Het gebruik van sessies heeft echter als belangrijk nadeel dat sommige Firewalls ze tegenhouden, waardoor deze gebruikers kunnen 'winkelen'. Nu is mijn vraag zijn er andere manieren om een UID te 'onthouden'in PHP? En hoe? (t liefst geen gebruik van cookies, want deze zijn ook vaak uitgeschakeld door beveiligingssoftware) BvD

[anoniem]

De reden dat de sessions niet werken achter bepaalde firewalls is dat deze de cookies met de session id tegenhouden. Wat je zou kunnen proberen is om een eigen session id te genereren en deze via het adres iedere keer mee te geven. Dit is echter wel erg moeilijk en erg omslachtig, ik denk dat je mensen beter kan wijzen op het feit dat ze hun firewall iets moeten aanpassen. - Bas

[anoniem]

Ik heb daar eens iets op bedacht. Ik laat de bezoeker inloggen, en na submitten krijgen ze zowel een cookie als een url met daar in de sessie id toegestuurd. Het script checkt vervolgens of er een cookie geplaatst is. Is die er wel, dan wordt er niks met de url gedaan, en verdwijnt de id daaruit. Is het koekje er niet, dan kijkt het naar de url, en blijft de id ook toevoegen in alle overige formulieren en links. Ik weet niet of je zo de standaard sessies in php nog kunt gebruiken, maar die gegevens kun je natuurlijk ook gewoon kwijt in een eigen tabel. Het verwijzen naar instellingen is niet altijd een oplossing. Veel mensen hebben daar geen zin in, of ze weten niet hoe het moet. Verder gaan cookies soms ook verloren bij cachende- of proxy servers. Naar mijn idee moet je er gewoon voor zorgen dat het werkt, anders is je klant zo weg.

[anoniem]

Ja naar mijn mening moet het ook 'gewoon', dat verwacht de klant ook. Het is aan de maker om een overal goed werkend pakket te ontwikkelen. Ik denk dat ik het ga proberen om via de URL door te geven, zou me normaal wel moeten lukken. Want iedereen heeft zijn PC weer anders ingesteld, de ene ondersteunt geen Cookies, de andere geen Sessies, kortom, via de URL lijkt het beste.

[anoniem]

Als webwinkel kan je best de voorwaarde stellen dat JavaScript ingeschakeld is. In dat geval heb je namelijk het ultieme voordeel van het JavaScript DOM waarmee je dynamisch aan elke (externe) link een session id kan plakken. Dit lijkt me de oplossing waarbij weinig werk en goede usability hand in hand gaan, en als mensen niet bereid zijn om daarvoor hun JavaScript in te schakelen... Tja, dan houdt het op. Het mooie van deze aanpak is dat mensen dit voor zichzelf kunnen bepalen, firewalls en routers hebben er niets mee te maken, over het algemeen kan iedereen dit zelf aan- of uitschakelen. - Bas

[anoniem]

Dynamisch via de DOM session id's toevoegen? En waar komt deze id dan vandaan? Waarom niet meteen server-side toevoegen? Als enige reden zou ik kunnen bedenken dat je daarvoor in de shopcode moet gaan zoeken naar a-tjes. Bovendien heeft via de DOM aanpassen wat mij betreft een groot nadeel en dat is dat je alles onload van de pagina moet doen. Een ongeduldige gebruiker die alvast op een link klikt terwijl de pagina nog niet helemaal klaar is met laden zal dus zonder session id verder navigeren.

[anoniem]

Mn voorkeur gaat naar aanleiding van jullie reacties toch uit naar het gewoon doorgeven van de variabelen via het adres, dus pagina.php?ID=x Om de artikelen van het 'winkelwagentje' te onthouden houd ik per bezoeker een UserID (UID) bij. Het UID is opgebouwd uit een lange datum string met het Remote Addr er aan vast geplakt. Dus: [code:1:90951f0dba] $dt=date("YmdHis"); $UID = "$dt$HTTP_SERVER_VARS[REMOTE_ADDR]"; [/code:1:90951f0dba] Volgens mij is dit uniek genoeg, en kunnen klanten zou niet door elkaar raken.

[anoniem]

waarom gebruik je niet [url=http://www.php.net/manual/en/function.uniqid.php]uniqid[/url]?

[anoniem]

Volgens mij wordt er te moeilijk nagedacht over dit probleem. In eerste instantie is het probleem al heel klein, want: - wie heeft blokkeren van cookies in zijn firewall aanstaan? Zelfs bij streng ingestelde firewalls kunnen gewoon cookies geaccepteerd worden. (kun je dit eigenlijk wel instellen in een firewall? Volgens mij gaat dit gewoon met http-protocol mee, dus hoe wil je dit blokkeren?) - cookies om het sessionId op te slaan zijn tijdelijke cookies die bij het sluiten van de browser verwijderd worden. Dit kan apart van de normale cookies worden ingesteld in de meeste browsers (waar je cookies uit kan zetten). Mensen die ook de tijdelijke cookies blokkeren weten dat ze dan functionaliteiten verliezen. De oplossing voor dit kleine probleem: - Het sessionId kun op twee manieren doorgegeven worden: 1. via de browser door een tijdelijke cookie; 2. door deze aan de URL mee te geven. Deze twee opties kunnen tergelijkertijd ingesteld worden, zodat als tijdelijke cookies niet mogelijk zijn er automatisch de sessionId uit de URL wordt gehaald. Dit hoef je niet met code uit de URL te halen, dit gebeurt automatisch. Je dient wel elke URL de sessionId mee te geven door <?php echo strip_tags (SID)?> bij je links te zetten of in de php.ini dit automatisch te laten doen. LET OP: dit levert wel een beveiligingrisico op, omdat het sessionId nu zichbaar is. Voorts vind ik het raar dat je een tijdlijke MySQL-tabel gebruikt voor deze situatie. Waarom niet het winkelmandje volledig in de session registreren, dan dat je elke keer weer naar de database gaat schrijven. Dus kortom: Waarom een alternatief voor sessions gebruiken? -Rémy

[anoniem]

[quote:f832641e63="Remytje"] Dus kortom: Waarom een alternatief voor sessions gebruiken? [/quote:f832641e63] Omdat ik enkele gebruikers ken, met norton, die niet in het winkelwagentje kunnen komen omdat de sessie niet opgeslagen word. En omdat ook zakelijke klanten vanaf kantoor moeten kunnen winkelen en in bedrijven zijn vaak veel functies uitgeschakeld. Ik heb 2 mailtjes gehad van zakelijke klanten moet klachten over de toegang van de webwinkel. Dit mag eigenlijk niet gebeuren, dus daarom een alternatief.

[anoniem]

[quote:cd69aec75d="George W. Bush"]Omdat ik enkele gebruikers ken, met norton, die niet in het winkelwagentje kunnen komen omdat de sessie niet opgeslagen word.[/quote:cd69aec75d]Even voor de duidelijkheid: Geen enkele firewall of browser kan sessies blokkeren!!! Waarom? Omdat sessies op de webserver bijgehouden worden! Dus je hoeft hier geen alternatief voor te bedenken! Het enigste wat de server dient te weten, is de sessionId, zodat de server de juiste sessie kan opzoeken. Als er dus bij elke request van de browser een sessionId mee wordt gestuurd, dan kan de server de klant herkennen. Hoe wordt een sessionId meegegeven? Middels een tijdelijk cookie (waar enkel de SessionId inzit) of in de URL. Cookies worden met de header meegestuurd en kunnen dus, volgens mij, niet geblokkerd worden door een firewall, want dan zou je niet eens kunnen internetten. [quote:cd69aec75d="George W. Bush"]En omdat ook zakelijke klanten vanaf kantoor moeten kunnen winkelen en in bedrijven zijn vaak veel functies uitgeschakeld. Ik heb 2 mailtjes gehad van zakelijke klanten moet klachten over de toegang van de webwinkel. Dit mag eigenlijk niet gebeuren, dus daarom een alternatief.[/quote:cd69aec75d]In de browser kan dus wel ingesteld worden of cookies geblokkerd kunnen worden. Meestel heb je de mogelijkheid om alle cookies te blokkeren of alleen de tijdelijke door te laten. En klanten\bedrijven die ALLE cookies uitzetten, weten dat ze hiermee functionaleiten verliezen. Snap ook niet waarom bedrijven dit instellen in hun browser, want cookies zijn niet echt een beveligingrisico. Ik werk bij een bedrijf dat deels afhankelijk is van internet, dus een streng beveiligingbeleid voert, maar cookies kunnen gewoon geaccepteerd worden. Maar wat ik al aangaf, óók zonder cookies, kun je sessies gebruiken. Stuur gewoon de SessionId met de URL mee en opgelost is je probleem! Dus nogmaal een alternatief voor sessies is niet nodig! Sessies zijn de oplossing hiervoor. En je kan dus ook je hele winkelmandje opslaan in de sessie (dit is ook de manier zoals de meeste webshops werken)... - Rémy

[anoniem]

[quote:273f67d92c="Remytje"]En je kan dus ook je hele winkelmandje opslaan in de sessie (dit is ook de manier zoals de meeste webshops werken)... [/quote:273f67d92c] Ik ken ook heel veel webshops waarbij de inhoud van het winkelmandje juist in een cookie of in de database worden opgeslagen. Waarop baseer je deze uitspraak?

[anoniem]

Sorry, mijn laatste zin iets te snel geformuleerd. D'r had eigenlijk moeten staan sessies en cookies, maar dat komt omdat ik sessies als server-side-cookies zie (en dat is het in principe ook). Ehh... ja, waar baseer ik die uitspraak op? Ik heb niet direct bronnen\links beschikbaar voor je, maar zeg dat uit mijn persoonlijke ervaring (kan natuurlijk fout zijn :wink:). Als ik zou gaan zoeken op internet naar bv tutorials over webshops dan zullen er, volgens mij, weinig zijn die voor de tijdelijk data een database gebruiken. Maar ik zeg niet dat het in de database niet opslaan niet kan\mag, maar waarom zou je zulke tijdelijke info in een database opslaan? Al je een multi-formulier (formulier met meedere schermen), sla je de data toch ook niet op tussen de schermen door? Die zet je in de URL, cookie of sessie, om bij het laatste scherm naar de database weg te schrijven. Stel dat de klant halverwege het bestellen, afziet van de bestelling, en dit zijn er bv. veel op een dag. Dan dien je dus bv. elke dag je database op te schonen.... En hoogst waarschijnlijk (zou ik moeten testen) is het wegschrijven in een database langzamer dan naar een cookie of session, dus heb je meteen een snelheidsvoordeel en je server wordt minder belast (helemaal als je web- en database-server op de zelfde pc draaien.) [quote:5e778cc9f5="BasHammer"]Als webwinkel kan je best de voorwaarde stellen dat JavaScript ingeschakeld is.[/quote:5e778cc9f5]Waarom zou je dan niet als voorwaarde kunnen stellen dat cookies (in ieder geval de tijdelijke) geaccepteerd moeten kunnen worden. Cookies vind ik minder 'gevaarlijk' dan javascript. -Rémy

[anoniem]

[quote:9b4c0ffb05="George W. Bush"] Nu is mijn vraag zijn er andere manieren om een UID te 'onthouden'in PHP? En hoe? [/quote:9b4c0ffb05] Je probleem wordt er niet anders van: UID of session id - je hebt sessie informatie nodig == info die over meerdere (en alle) pagina's meegenomen wordt. Drie mogelijkheden: [code:1:9b4c0ffb05] ini_set('session.use_trans_sid', TRUE); ini_set('session.use_cookies', FALSE); [/code:1:9b4c0ffb05] Als het [b:9b4c0ffb05]effectief[/b:9b4c0ffb05] alleen om de uid gaat, zou'k geen sessies gebruiken, maar een functie: [code:1:9b4c0ffb05] function createLink($to, $text=FALSE) { $text = ($text) ? $text : $to; if( strstr('?', $to) ) { $to .= '&'; } else { $to .= '?'; } $to .= 'uid=' . $_REQUEST['uid']; return "<a href=\"$to\">$text</a>"; } [/code:1:9b4c0ffb05] Vervolgens in elk formulier een 'hidden' input opnemen. Dit is overigens exact wat trans_sid al voor je doet, maar het scheelt de overhead van sessie files in je tmp dir en bijbehorende flocks. De shop informatie moet je dan wel ergens opslaan, wat eigenlijk leidt tot de derde en denk ik beste oplossing: De ini-configs van de eerste code en je eigen sessie handler, via session.save_handler en session_set_save_handler.

[anoniem]

[quote:2daad06a12="Remytje"] Ehh... ja, waar baseer ik die uitspraak op? Ik heb niet direct bronnen\links beschikbaar voor je, maar zeg dat uit mijn persoonlijke ervaring (kan natuurlijk fout zijn :wink:). [/quote:2daad06a12] Zoals ik al aangaf zegt mijn persoonlijke ervaring wat anders. Namelijk dat je dit niet zo stellig kan beweren (maar daar was je het zelf ook al een beetje mee eens als ik je niet verkeerd begrijp). Overigens zou het best kunnen dat er vaker weggeschreven wordt in sessies/cookies (t.o.v. de database) dat wil ik niet weerleggen. Alleen betekend dat m.i. niet meteen dat het ook beter is. Bovendien zou ik dan ook graag bewijzen zien :) [quote:2daad06a12="Remytje"] Als ik zou gaan zoeken op internet naar bv tutorials over webshops dan zullen er, volgens mij, weinig zijn die voor de tijdelijk data een database gebruiken. [/quote:2daad06a12] Dit noemt men ook wel een aanname en zegt dus niet zo heel erg veel over de werkelijkheid ;) [quote:2daad06a12="Remytje"] maar waarom zou je zulke tijdelijke info in een database opslaan? Al je een multi-formulier (formulier met meedere schermen), sla je de data toch ook niet op tussen de schermen door? [/quote:2daad06a12] Soms doe je dat dus wel. Ik heb meerdere applicaties gemaakt waarbij het van belang is dat een gebruiker niet tussentijds zijn data verliest. Bij bijvoorbeeld het afsluiten of crashen van een browser of tussentijds verwijderen van een cookie zou dat betekenen dat de gebruiker alle data kwijt is (en dat verhelp je ook niet met een sessie). En deze functionele eis kan je dus ook verbinden aan een winkelmandje in een webshop. [quote:2daad06a12="Remytje"] Stel dat de klant halverwege het bestellen, afziet van de bestelling, en dit zijn er bv. veel op een dag. Dan dien je dus bv. elke dag je database op te schonen.... [/quote:2daad06a12] Elke zichzelf respecterende database heeft mogelijkheden om dit te automatiseren. En bovendien zal je toch maintenance moeten doen aan de database, dus dan kan dit er ook wel bij. En sessies die 'afgebroken' worden? Waar gaan die naar toe? Juist, die worden ook opgeschoond. Dus ik zie het verschil niet. [quote:2daad06a12="Remytje"] En hoogst waarschijnlijk (zou ik moeten testen) is het wegschrijven in een database langzamer dan naar een cookie of session [/quote:2daad06a12] Als de performance van een webshop achteruit holt omdat er een beetje data weggeschreven wordt in een database dan zou ik me eens goed achter de oren krabben ;) [quote:2daad06a12="Remytje"] dus heb je meteen een snelheidsvoordeel en je server wordt minder belast (helemaal als je web- en database-server op de zelfde pc draaien.) [/quote:2daad06a12] En sessies bijhouden kost geen extra performance?

[anoniem]

[quote:6e4f8d21f6="Annie"]maar daar was je het zelf ook al een beetje mee eens als ik je niet verkeerd begrijp.[/quote:6e4f8d21f6]Klopt :wink: [quote:6e4f8d21f6="Annie"]Alleen betekend dat m.i. niet meteen dat het ook beter is.[/quote:6e4f8d21f6]Heb je helemaal gelijk in: iets wat veel wordt toegepast wil niet meteen zeggen dat het automatisch het beste is. [quote:6e4f8d21f6="Annie"]Soms doe je dat dus wel. Ik heb meerdere applicaties gemaakt waarbij het van belang is dat een gebruiker niet tussentijds zijn data verliest.[/quote:6e4f8d21f6]Oké, in die gevallen is het wegschrijven naar de database inderdaad handig, want blijkbaar is die data zo belangrijk dat als dit niet meer terug te halen is, er problemen ontstaan in de bedrijfsgang, dus dient dit direct weggeschreven te worden (denk aan telefonische reserveringen voor een hotel registeren). Maar hoe vaak is dit echt nodig (bij een webshop zie ik die noodzaak even niet)? [quote:6e4f8d21f6="Annie"]Bij bijvoorbeeld het afsluiten of crashen van een browser of tussentijds verwijderen van een cookie zou dat betekenen dat de gebruiker alle data kwijt is (en dat verhelp je ook niet met een sessie). En deze functionele eis kan je dus ook verbinden aan een winkelmandje in een webshop.[/quote:6e4f8d21f6]Klopt met een sessie zo bij het crashen of sluiten van de browser de data kwijt zijn. Ik zou dan voor cookies gaan, ondanks dat er een beperkt aantal mensen dit uit heeft staan, zodat de data toch beschikbaar is. En iemand die tussentijds zijn cookie verwijderdt, tja, tuurlijk kan dit gebeuren en dan ben je het kwijt, maar hoe vaak gebeurt dit? Voorts stel dat je deze data heb weggeschreven in een database en de browser afsluit en hij heeft zijn cookies gewist en de klant nog verwacht dat hij verder kan gaan met bestellen waar hij was gebleven (nogmaals hoe vaak gebeurt dit?), hoe herken je deze gebruiker dan opnieuw? Dit kan alleen als klanten dienen in te loggen voordat ze mogen bestellen en dit verhoogt de drempel om te bestellen, dus kost je geld! En deze functionele eis kun je er aan een webshop verbinden, maar elke eis kan meer tijd kosten, dus meer geld. Dan speelt (voor mij althans) de keuze: laat ik een aantal eisen vallen, zodat het goedkoper wordt of hou ik die eisen aan voor 1% van de bezoekers en kost mij dit meer geld. Dit kan ik natuurlijk niet beoordelen voor dit speciefieke geval, maar dan begrijp je een beetje hoe ik er inzit. [quote:6e4f8d21f6="Annie"]Elke zichzelf respecterende database heeft mogelijkheden om dit te automatiseren. En bovendien zal je toch maintenance moeten doen aan de database, dus dan kan dit er ook wel bij.En sessies die 'afgebroken' worden? Waar gaan die naar toe? Juist, die worden ook opgeschoond. Dus ik zie het verschil niet.[/quote:6e4f8d21f6]Heb je gelijk in, maar dit komt omdat omdat ik, vanuit de programeerhoek gekeken, het als tijdelijke data zie en er geen waarde, uitzonderingen daargelaten, in zie om dit tussentijds op te slaan in een database. Ik zie cookie en sessions als de plek om deze data te bewaren. Dit wil niet zeggen dat ik tegen sessions ben die naar de database wegschrijven (zoals melvyn kort noemde) dmv een custom session handeler, want daar zitten óók voordelen aan als je die nodig hebt (aan een pure website zie ik het voordeel hiervan even niet). Dus kortom: Kan ik wel meegaan met jouw argumenten en geef ik je ook gelijk, maar voor mij speelt de kosten-baten-analyse een grote rol en het feit dat ik vind dat zeer tijdelijke data niet in een database thuis hoort als dit geen nut heeft (en er zijn gevallen waar dit wel weer nut heeft) -Rémy