Sessions and browsertabs

[Erick T. Barkhuis]

De vraag in het kort:
hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
een tabblad - maar niet de browser - sluit?

===

Nu de lange vorm:

Een webshop met winkelwagen is in ontwikkeling (maatwerk). De webshop
bestaat uit verschillende afdelingen. Er is echter slechts 1 winkelwagen
en 1 kassa. Een huisregel luidt: tijdens e1n sessie is het niet
toegestaan artikelen uit meerdere afdelingen tegelijkertijd in de
winkelwagen te plaatsen (en te bestellen). Het is echter wel toegestaan
met gevulde kar rond te kijken in andere afdelingen.

Om dit te realiseren wordt een sessie-variabele bijgehouden, waarin de
afdeling wordt vastgelegd. Deze vastlegging vindt plaats zodra het eerste
artikel in de kar wordt gelegd. Deze variabele wordt 'schoongepoetst':
- als de bezoeker het enige of laatste artikel uit de winkelkar
verwijdert
- als de bezoeker de bestelling voltooit.
Bovendien wordt alles door de browser weggeknikkerd als de bezoeker de
browser afsluit, maar met toekomstige Session Managers (zoals in FF2.0)
kan ook dat feest wel eens voorbij zijn.

Het probleem:
Nadat een bezoeker enkele artikelen uit Afdeling-A in de winkelwagen
heeft gelegd houdt hij het voor gezien, en drukt op de tabblad-sluitknop.
Het tabblad is weg, maar de browser blijft leven.
Voor zijn gevoel heeft de klant de winkel verlaten!!
Vervolgens opent hij een nieuw tabblad en gaat, bijvoorbeeld middels een
bookmark, naar Afdeling-B van de webshop om een artikel te bestellen.
Nu blijkt dat Firefox de sessie nog steeds heeft openstaan (dit is ook
conform alle documentatie die ik inmiddels heb gelezen). Het PHP-script
leest in de sessie-variabele dat de klant nog bezig is in Afdeling-A, en
staat hem niet toe een artikel uit Afdeling-B in de wagen te leggen.
Dat is technisch misschien correct, maar niet wat ik wil.

Ik zoek naar een oplossing, en zie er een paar:
a. Gooi alle sessie-variabelen weg als de bezoeker het
tabblad sluit of het domein verlaat
b. Sta binnen de winkel niet toe dat een klant een andere
Afdeling binnenstapt met zijn gevulde kar
c. Negeer het probleem...een bezoeker moet maar voldoende
kennis van zaken hebben om te weten dat de sessie op die
manier in leven blijft. Leg dat desnoods op de site uit.

Mijn voorkeur gaat naar oplossing-a, en ik zou een suggestie hoe dat te
realiseren enorm op prijs stellen.

--
Erick

[Hans]

On Mon, 18 Sep 2006 18:40:49 +0200,
Erick T Barkhuis <erick.usenet@ardane.c-o-m> wrote:
>
>
> a. Gooi alle sessie-variabelen weg als de bezoeker het
> tabblad sluit of het domein verlaat
> b. Sta binnen de winkel niet toe dat een klant een andere
> Afdeling binnenstapt met zijn gevulde kar
> c. Negeer het probleem...een bezoeker moet maar voldoende
> kennis van zaken hebben om te weten dat de sessie op die
> manier in leven blijft. Leg dat desnoods op de site uit.
>
> Mijn voorkeur gaat naar oplossing-a, en ik zou een suggestie hoe dat te
> realiseren enorm op prijs stellen.

Volgens mij is dat alleen maar mogelijk met specifieke browsers. Het
is denk ik niet een goed idee om clientside vast te houden wat je eigenlijk
serverside wil afvangen.

http://kb.mozillazine.org/Browser.tabs.selectOwnerOnClose#Background

Je zou natuurlijk voor b kunnen kiezen en een extra sessie var kunnen
opnemen waarbij je checked in welke afdeling ze nog spullen hebben
zitten. Komen ze op een andere afdeling binnen dan redirect je ze naar
de oude afdeling of geeft ze de keuze om de oude afdeling te legen en
door te gaan naar de nieuwe.

Groet,

Hans

--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn
IM: hans.wolters@jabber.xs4all.nl
http://blacklist.kernelnewbies.nl

[robert]

Erick T Barkhuis <erick.usenet@ardane.c-o-m>:
> De vraag in het kort:
> hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
> een tabblad - maar niet de browser - sluit?

Vanuit een onbeforeunload() een schoonmaak-url aanroepen die je
sessievariabelen opruimt?

--
robert

[Erick T. Barkhuis]

robert:
> Erick T Barkhuis <erick.usenet@ardane.c-o-m>:
> > De vraag in het kort:
> > hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
> > een tabblad - maar niet de browser - sluit?
>
> Vanuit een onbeforeunload() een schoonmaak-url aanroepen die je
> sessievariabelen opruimt?

Dank voor je suggestie.
Het probleem is, dat die schoonmaak-url zijn ding ook zou doen als de
bezoeker _binnen_ dezelfde afdeling de winkelwagen verlaat om verder te
shoppen. En dan moeten de sessie-variabelen natuurlijk wel overeind
blijven. Er zijn veel situaties waarbij tijdens unload() de status
bewaard moet blijven.

Ik zie niet zo gauw een mogelijkheid om te differentieren naar 'reden'
waarom de bezoeker die ene winkelwagenpagina verlaat.


--
Erick

[Arnold Hendriks]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote in message
news:MPG.1f78fea08e5d0d8898a16a@news.individual.ne t...
> robert:

>> Vanuit een onbeforeunload() een schoonmaak-url aanroepen die je
>> sessievariabelen opruimt?

> Dank voor je suggestie.
> Het probleem is, dat die schoonmaak-url zijn ding ook zou doen als de
> bezoeker _binnen_ dezelfde afdeling de winkelwagen verlaat om verder te
> shoppen. En dan moeten de sessie-variabelen natuurlijk wel overeind
> blijven. Er zijn veel situaties waarbij tijdens unload() de status
> bewaard moet blijven.
>
> Ik zie niet zo gauw een mogelijkheid om te differentieren naar 'reden'
> waarom de bezoeker die ene winkelwagenpagina verlaat.

De unload handlers gebruiken, en die resetten zodra iemand ergens op een
link klikt zodat hij in dat geval niet aangeroepen wordt. Dan heb je wel
onderscheid tussen klikken op een van jouw links, maar nog geen onderscheid
tussen het sluiten van een tab of het slepen van een bookmark naar diezelfde
tab.

[Erick T. Barkhuis]

Hans:
> On Mon, 18 Sep 2006 18:40:49 +0200,
> Erick T Barkhuis <erick.usenet@ardane.c-o-m> wrote:

[oplossingsmogelijkheden]
> > b. Sta binnen de winkel niet toe dat een klant een andere
> > Afdeling binnenstapt met zijn gevulde kar
>
> Je zou natuurlijk voor b kunnen kiezen en een extra sessie var kunnen
> opnemen waarbij je checked in welke afdeling ze nog spullen hebben
> zitten.

Die 'extra' sessievariabele is er al.

> Komen ze op een andere afdeling binnen dan redirect je ze naar
> de oude afdeling of geeft ze de keuze om de oude afdeling te legen en
> door te gaan naar de nieuwe.

Dankjewel voor je suggestie, Hans. Dit is inderdaad een mogelijkheid,
maar er zijn twee complicaties waardoor die oplossing me eigenlijk wat
tegenstaat:

1. Perceptie bij de bezoeker.
Ik kan me voorstellen dat de bezoeker, die die keuze krijgt, denkt: "Huh?
Wat nou andere afdeling? Ik heb toch netjes mijn vorige scherm gesloten
en de winkel verlaten? Waarom denkt dat stomme ding dat ik nog in
Afdeling-A zit?"

2. Technische bijkomstigheid
De (al wat oudere) winkel bestaat grotendeels uit statische html-pagina's
waarbij de keuze voor een artikel middels query-string wordt doorgegeven
aan de winkelwagen. Het winkelwagenscript en het checkout-script zijn
momenteel de enige php-scripts waarin de sessie-variabelen bekend zijn.
Om de door jou geschilderde oplossing te realiseren moet ik erg veel
html-pagina's omvormen tot php-scripts waarin ik die waarschuwing/keuze
zou kunnen presenteren.
Alternatieven als httpRequest of het aanroepen van een PHP-controlescript
in elke html-winkelpagina is mogelijk, maar dan blijft punt-1 hierboven
nog overeind.


--
Erick

"A journey of a thousand miles begins with a single step." - Lao-Tse

[Martin]

Hieronder volgt een reactie op dit bericht:
>>> Vanuit een onbeforeunload() een schoonmaak-url aanroepen die je
>>> sessievariabelen opruimt?
>
>> Dank voor je suggestie.
>> Het probleem is, dat die schoonmaak-url zijn ding ook zou doen als de
>> bezoeker _binnen_ dezelfde afdeling de winkelwagen verlaat om verder
>> te shoppen. En dan moeten de sessie-variabelen natuurlijk wel
>> overeind blijven. Er zijn veel situaties waarbij tijdens unload() de
>> status bewaard moet blijven.
>>
>> Ik zie niet zo gauw een mogelijkheid om te differentieren naar
>> 'reden' waarom de bezoeker die ene winkelwagenpagina verlaat.
>
> De unload handlers gebruiken, en die resetten zodra iemand ergens op
> een link klikt zodat hij in dat geval niet aangeroepen wordt. Dan heb
> je wel onderscheid tussen klikken op een van jouw links, maar nog
> geen onderscheid tussen het sluiten van een tab of het slepen van een
> bookmark naar diezelfde tab.

Ik snap niets van PHP maar kun je niet gewoon zeggen dat bij een artikel uit
afdeling B gecontroleerd wordt of er iets uit A in de wagen zit. Zo ja een
foutmelding geven, zo nee het artikel in de wagen plaatsen?

Groetjes Martin.

--
Gratis je eigen radiozender, een muziek cd branden en meer...
http://winampnederlands.nl/

[Erick T. Barkhuis]

Martin:

> Ik snap niets van PHP maar kun je niet gewoon zeggen dat bij een artikel uit
> afdeling B gecontroleerd wordt of er iets uit A in de wagen zit. Zo ja een
> foutmelding geven, zo nee het artikel in de wagen plaatsen?

Hoi Martin. Dankjewel!
Maar...dat is precies wat er nu gebeurt. Het werkt ook goed, dus je
suggestie is prima.
Het geschilderde probleem is echter, dat bij het sluiten van een tabblad
de sessie-variabelen (dus zeg maar: het lijstje artikelen in de
winkelwagen en de afdelingsnaam) bewaard worden in de browser. Ga je
daarna opnieuw naar de winkel - bijvoorbeeld in een ander tabblad, of
nadat je als een dolle op andere sites hebt gesurft) dan denkt de
bezoeker dat-ie "opnieuw begint" terwijl de browser daar anders over
denkt.

Ik moet dus eigenlijk de browser een handje helpen door duidelijk te
maken dat bij het sluiten van een tabblad - of bij het tussentijds elders
rondsurfen - de sessie-variabelen weggeknikkerd kunnen worden.

--
Erick

"Dat is allemaal goed en wel in de praktijk, maar het zal het nooit doen
in theorie."

[Hans]

On Mon, 18 Sep 2006 20:15:01 +0200,
Erick T Barkhuis <erick.usenet@ardane.c-o-m> wrote:
> Hans:

[winkelwagen]
>
>> Komen ze op een andere afdeling binnen dan redirect je ze naar
>> de oude afdeling of geeft ze de keuze om de oude afdeling te legen en
>> door te gaan naar de nieuwe.
>
> Dankjewel voor je suggestie, Hans. Dit is inderdaad een mogelijkheid,
> maar er zijn twee complicaties waardoor die oplossing me eigenlijk wat
> tegenstaat:
>
> 1. Perceptie bij de bezoeker.
> Ik kan me voorstellen dat de bezoeker, die die keuze krijgt, denkt: "Huh?
> Wat nou andere afdeling? Ik heb toch netjes mijn vorige scherm gesloten
> en de winkel verlaten? Waarom denkt dat stomme ding dat ik nog in
> Afdeling-A zit?"
>
> 2. Technische bijkomstigheid
> De (al wat oudere) winkel bestaat grotendeels uit statische html-pagina's
> waarbij de keuze voor een artikel middels query-string wordt doorgegeven
> aan de winkelwagen. Het winkelwagenscript en het checkout-script zijn
> momenteel de enige php-scripts waarin de sessie-variabelen bekend zijn.
> Om de door jou geschilderde oplossing te realiseren moet ik erg veel
> html-pagina's omvormen tot php-scripts waarin ik die waarschuwing/keuze
> zou kunnen presenteren.
> Alternatieven als httpRequest of het aanroepen van een PHP-controlescript
> in elke html-winkelpagina is mogelijk, maar dan blijft punt-1 hierboven
> nog overeind.

Met de statische html is het wel te realiseren maar het vergt wel meer
load op de server. Je kunt een php script maken dat de checks voor je
doet en die preloaden voor je de <pagina.html> gaat laden. In dat php
script check je je voorwaardes en geef je een header mee naar een
waarschuwing op het moment dat de voorwaarde voldoet.

http://nl3.php.net/manual/en/ini.core.php#ini.auto-prepend-file

Je moet op dat moment wel alle html pagina's door de php engine laten
parsen, iets wat je wellicht liever niet doet.

Groet,

Hans

--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn
IM: hans.wolters@jabber.xs4all.nl
http://blacklist.kernelnewbies.nl

[Ronald Klip]

18-09-2006 20:28, Erick T. Barkhuis:

> Het geschilderde probleem is echter, dat bij het sluiten van een tabblad
> de sessie-variabelen (dus zeg maar: het lijstje artikelen in de
> winkelwagen en de afdelingsnaam) bewaard worden in de browser. Ga je
> daarna opnieuw naar de winkel - bijvoorbeeld in een ander tabblad, of
> nadat je als een dolle op andere sites hebt gesurft) dan denkt de
> bezoeker dat-ie "opnieuw begint" terwijl de browser daar anders over
> denkt.

Maar ook dan kun je toch adhv het request bepalen waar je zit en spullen
van de andere afdeling weggooien uit het mandje (= de betreffende
sessievariabele)?


--
groet, Ronald

[Erick T. Barkhuis]

Ronald Klip:
> 18-09-2006 20:28, Erick T. Barkhuis:
>
> > Het geschilderde probleem is echter, dat bij het sluiten van een tabblad
> > de sessie-variabelen (dus zeg maar: het lijstje artikelen in de
> > winkelwagen en de afdelingsnaam) bewaard worden in de browser. Ga je
> > daarna opnieuw naar de winkel - bijvoorbeeld in een ander tabblad, of
> > nadat je als een dolle op andere sites hebt gesurft) dan denkt de
> > bezoeker dat-ie "opnieuw begint" terwijl de browser daar anders over
> > denkt.
>
> Maar ook dan kun je toch adhv het request bepalen waar je zit en spullen
> van de andere afdeling weggooien uit het mandje (= de betreffende
> sessievariabele)?

Ik denk dat ik het misschien wat te verwarrend heb geschilderd.

Het is op zich niet erg relevant waar een bezoeker 'zit'. Hij mag overal
in de winkels/afdelingen rondkijken. Pas als zhij:
a) artikelen uit de ene afdeling in de kar heeft, EN
b) een artikel toevoegt uit een andere afdeling
....moet dat worden tegengegaan met een passende foutboodschap.

Als de sessievariabelen nog bestaan (na het sluiten van een tabblad) en
de bezoeker gaat een tijdje erna pardoes naar een andere afdeling, dan is
hij op zich nog niet in overtreding, en hoeft er niks weggegooid te
worden. De verrassing is alleen groot als hij iets gaat bestellen uit die
andere afdeling en de scripts wijzen hem er op dat-ie nog een karretje
vol heeft met afdelingsvreemde artikelen.

--
Erick

"I have a theory that the truth is never told during the 9 to 5 hours." -
Hunter S. Thompson

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:

> De vraag in het kort:
> hoe kun je met PHP een $_SESSION-array leegmaken wanneer de
> sitebezoeker een tabblad - maar niet de browser - sluit?

Dat kan zo natuurlijk niet omdat 'PHP' geen weet heeft van tabbladen
en windows etc. Je hebt het m.i. voornamelijk over een client-side
kwestie, n.l. het (hier en daar) delen & voortleven van tijdelijke/
session cookies.

Je kunt, zoals opgemerkt, natuurlijk wel een event afhandelen, zoals
unload, maar dat zal met enige voorzichtigheid moeten gebeuren.
(Alleen muiskliks afhandelen is niet genoeg.)

Altijd een unieke ID uitdelen en propageren maakt e.e.a. natuurlijk
simpeler, al heeft 't schaduwzijden.... (Als je de gehele winkel,
heel onvriendelijk, m.b.v. client-side script laat marcheren onder
1 URL dan is het gebruik van zo'n unieke ID geen probleem.)

WD

[Erick T. Barkhuis]

Warden Dave:
> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
>
> > De vraag in het kort:
> > hoe kun je met PHP een $_SESSION-array leegmaken wanneer de
> > sitebezoeker een tabblad - maar niet de browser - sluit?
>
> Dat kan zo natuurlijk niet omdat 'PHP' geen weet heeft van tabbladen
> en windows etc.

Klopt. Ik hoopte op alternatieven die hier dichtbij liggen.

> Je kunt, zoals opgemerkt, natuurlijk wel een event afhandelen, zoals
> unload, maar dat zal met enige voorzichtigheid moeten gebeuren.
> (Alleen muiskliks afhandelen is niet genoeg.)

Dat je ook op andere manieren die unload kunt veroorzaken is helder. Maar
aan 'unload' kan ik slechts zien dat de huidige pagina wordt verlaten.
Zoals gezegd, dat is OK en komt in de meest gangbare situaties voor (de
bezoeker winkelt nog even verder). Als de bezoeker botweg het tabblad
sluit zal ook wel een unload worden afgevuurd, maar kan ik die
onderscheiden van andere unloads?

>
> Altijd een unieke ID uitdelen en propageren maakt e.e.a. natuurlijk
> simpeler,

Is zo'n ID dan niet weer een sessie-variabele, die ongewenst blijft
bestaan in gevallen waarin ik graag zou willen dat de hele sessie wordt
leeggepoetst: het wegklikken van het tabblad of het verlaten van het
domein.

--
Erick

"Ik kan niet meer zo vlug schrijven als vroeger. Ik word een beetje
langzamerhand"

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> Warden Dave:
>> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:

>> Je kunt, zoals opgemerkt, natuurlijk wel een event afhandelen, zoals
>> unload, maar dat zal met enige voorzichtigheid moeten gebeuren.
>> (Alleen muiskliks afhandelen is niet genoeg.)

> Dat je ook op andere manieren die unload kunt veroorzaken is helder.
> Maar aan 'unload' kan ik slechts zien dat de huidige pagina wordt
> verlaten. Zoals gezegd, dat is OK en komt in de meest gangbare
> situaties voor (de bezoeker winkelt nog even verder). Als de bezoeker
> botweg het tabblad sluit zal ook wel een unload worden afgevuurd,
> maar kan ik die onderscheiden van andere unloads?

Bijv. door alle relevente event op objecten die een verandering van URL
kunnen veroorzaken af te handelen. Nog sluitender is het de verandering
van URL uitsluitend via een script-functie te laten verlopen, maar wie
weet sluit je dan een paar mensen met afwijkende bedienings/invoer-
apparaten buiten (wanneer geen focus/click/keypress/etc.-event plaats-
grijpt. Je kunt makkelijk 'onload' de handler(s) aan de objecten
verbinden.

Wat je dan bijv. doen kunt is het koekje wissen en/of middels een
request (desnoods m.b.v. een Image Object o.i.d.) aan de server-kant
duidelijk maken dat 'id' aan z'n eind is (je kunt altijd /een/ ID
ook in script (/text) wegschrijven.

>> Altijd een unieke ID uitdelen en propageren maakt e.e.a. natuurlijk
>> simpeler,
>
> Is zo'n ID dan niet weer een sessie-variabele, die ongewenst blijft
> bestaan in gevallen waarin ik graag zou willen dat de hele sessie
> wordt leeggepoetst: het wegklikken van het tabblad of het verlaten
> van het domein.

Als de voorwaarde is dat de query-string met ID komt dan hoef je nog
slechts uit te vissen of de ID te oud is en wel gelijk aan de
genoteerde ID in een eventueel koekje. Eigenlijk zou een sessie moeten
beginnen met een request zonder ID (maar ja, 1 schaduwzijde is dat
gehele URI's, dus met query-string, kunnen worden opgeslagen).

WD

[Hans]

On Mon, 18 Sep 2006 21:51:14 +0200,
Warden Dave <warden_dave@mnsys.invalid> wrote:

> Als de voorwaarde is dat de query-string met ID komt dan hoef je nog
> slechts uit te vissen of de ID te oud is en wel gelijk aan de
> genoteerde ID in een eventueel koekje.

Maar wat nu als ik even naar een andere site ga en vervolgens gewoon
terug kom en mijn wagentje gewoon verder wil vullen?

Hans
--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn
IM: hans.wolters@jabber.xs4all.nl
http://blacklist.kernelnewbies.nl

[Warden Dave]

"Hans" <replyelsewhere@hans.kernelnewbies.nl> wrote:
> Warden Dave <warden_dave@mnsys.invalid> wrote:

>> Als de voorwaarde is dat de query-string met ID komt dan hoef je
>> nog slechts uit te vissen of de ID te oud is en wel gelijk aan de
>> genoteerde ID in een eventueel koekje.

> Maar wat nu als ik even naar een andere site ga en vervolgens gewoon
> terug kom en mijn wagentje gewoon verder wil vullen?

Tsja, dat wat Erick wil is dat ook bij een stap buiten de winkel de sessie
ten einde is en dan komt het eventuele gedrag van een UA dat een session
cookie ophoud te bestaan als het domein wordt verlaten mooi uit. Daar kwam
nog bovenop dat hij client-side script wilde inzetten dat ook 'onunload
naar den vreemde' gelijk de banden met de klant doorsneed, dus...

Als dat alles een bezwaar is moet er maar buiten zijn deur worden
gewinkeld in een nieuwe window/tab/anders.

WD

[Erick T. Barkhuis]

Warden Dave:
> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> > Warden Dave:
> >> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
>
> >> Je kunt, zoals opgemerkt, natuurlijk wel een event afhandelen, zoals
> >> unload, maar dat zal met enige voorzichtigheid moeten gebeuren.
>
> > Als de bezoeker
> > botweg het tabblad sluit zal ook wel een unload worden afgevuurd,
> > maar kan ik die onderscheiden van andere unloads?
>
> Bijv. door alle relevente event op objecten die een verandering van URL
> kunnen veroorzaken af te handelen.

Oei...dat zijn er in dit geval een hoop. Maar goed, het aantal is eindig,
dus het kan.

> Nog sluitender is het de verandering van URL uitsluitend via
> een script-functie te laten verlopen,

Ah, juistem. Een tussenliggend script dat doorstuurt en iets meegeeft.
Dat 'iets' kan dan aan gene zijde worden afgevangen.

Daarstraks zat ik even te denken, dat ik wellicht ook 'overal' de
refer[r]er kan uitvragen en op basis daarvan verder handelen. Even
afgezien van het feit dat die soms niet wordt doorgegeven, levert me dat
eigenlijk weer (net als met dat tussenliggende script) hetzelfde probleem
op: ik moet dan heel erg veel statische pagina's ombouwen.


Wat zou het toch fijn zijn als er bijvoorbeeld een http-header zou
bestaan die de browser bij de start van een sessie zou kunnen vertellen:
"Beschouw dit tabblad als een browser-instantie. Wordt het gesloten,
verwijder dan alle sessie-gegevens - net zoals je doet als de hele
browser wordt uitgeschakeld. Oh ja, doe dat ook als de bezoeker naar een
ander domein toegaat binnen dit tabblad."
[Wishful thinking, vrees ik]

--
Erick
[...die zich nog vast had voorgenomen niet op elke suggestie "ja,
maar..." te roepen, wat hem zo eigen is.]

[Erick T. Barkhuis]

Warden Dave:

> ...en dan komt het eventuele gedrag van een UA dat een session
> cookie ophoud te bestaan als het domein wordt verlaten mooi uit.

Hee, dat wist ik niet.

Dus als een sessie gaande is, en ik ga als bezoeker in hetzelfde tabblad
even naar - zeg - Google, ga dan met een bookmark weer naar de site waar
ik de sessie startte, dan zijn alle sessie-gegevens weg?

Echt?
Ik ga dat eens proberen....dankjewel.

[...voert test uit...]

[...en nog eens...]


Sjips. :-(
Mijn browser weet ook niet dat dat zo moet.

--
Erick

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:

> Wat zou het toch fijn zijn als er bijvoorbeeld een http-header zou
> bestaan die de browser bij de start van een sessie zou kunnen vertellen:
> "Beschouw dit tabblad als een browser-instantie. Wordt het gesloten,
> verwijder dan alle sessie-gegevens - net zoals je doet als de hele
> browser wordt uitgeschakeld. Oh ja, doe dat ook als de bezoeker naar
> een ander domein toegaat binnen dit tabblad."
> [Wishful thinking, vrees ik]

Sommige van je wensen zullen al het gedrag van sommige UAs zijn. Sommige
andere mensen hadden weer andere wensen, als:
http://groups.google.nl/group/netscape.public.mozilla.wishlist/browse_frm/thread/b167a1debb035acf/37dc2e78520d5d14
http://groups.google.nl/group/netscape.public.mozilla.wishlist/msg/107a26d508e25bdb
etc.

('t Is kortom nog een beetje een x-browser rommeltje met die
session-cookies en tabs.)

WD

[Erick T. Barkhuis]

Warden Dave:

> Sommige van je wensen zullen al het gedrag van sommige UAs zijn.

Dat lijkt me een mooie afsluitende gedachte van deze avond. Ik ga maar
eens mijn nachtelijke plichten vervullen op dit - voor deze streek - late
tijdstip.

--
Erick

"Sommige van je wensen zullen al het gedrag van sommige UAs zijn" - WD in
niws-s

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> Warden Dave:

>> ...en dan komt het eventuele gedrag van een UA dat een session
>> cookie ophoud te bestaan als het domein wordt verlaten mooi uit.

> Hee, dat wist ik niet.

Let op dat er staat 'eventuele gedrag' (d.w.z.: reken er niet op dat..).
Meer gebruikelijk is/was dat tijdelijke cookies pas bij het verlaten van
de browser ophielden te bestaan. [Dus in de geest van de slag om de arm
van bijv. cookiecentral.com: "If Expires is not set explicitly, then it
defaults to end-of-session. The length of a session can vary depending on
browsers and servers, but generally a session is the length of time that
the browser is open for (even if the user is no longer at that site)."] Nu
zou het bijv. zomaar zo /kunnen/ zijn dat 't koekje toch ook verdwijnt als
tabs gesloten worden.

> Dus als een sessie gaande is, en ik ga als bezoeker in hetzelfde tabblad
> even naar - zeg - Google, ga dan met een bookmark weer naar de site
> waar ik de sessie startte, dan zijn alle sessie-gegevens weg?
>
> Echt?
> Ik ga dat eens proberen....dankjewel.
>
> [...voert test uit...]

Eh, welke UA is hier de toetssteen?

> [...en nog eens...]
>
>
> Sjips. :-(
> Mijn browser weet ook niet dat dat zo moet.

Niemand zei dat 't zo /moet/ en met de behoefte de sessie op te laten
houden als je domein verlaten wordt zouik van eventuele medewerking geen
punt maken...

WD

[Arnold Hendriks]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote in message
news:MPG.1f790399ad9788c898a16c@news.individual.ne t...

> winkelwagen en de afdelingsnaam) bewaard worden in de browser. Ga je
> daarna opnieuw naar de winkel - bijvoorbeeld in een ander tabblad, of
Kun je dan niet aan het begin van de winkel het mandje hoe dan ook clearen?

[Arnold Hendriks]

"Warden Dave" <warden_dave@mnsys.invalid> wrote in message
news:eemus3$2ev2$1@nl-news.euro.net...

> Tsja, dat wat Erick wil is dat ook bij een stap buiten de winkel de sessie
> ten einde is en dan komt het eventuele gedrag van een UA dat een session
> cookie ophoud te bestaan als het domein wordt verlaten mooi uit.
Ik kan me wel wat dingen voorstellen die misgaan met zo'n browser, zoals
single sign-on applicatie die tussen domeinen werken. Heb je een voorbeeld
van zo'n UA ?

[Warden Dave]

"Arnold Hendriks" <a.hendriks@student.utwente.nl> wrote:
> "Warden Dave" <warden_dave@mnsys.invalid> wrote:

>> Tsja, dat wat Erick wil is dat ook bij een stap buiten de winkel de
>> sessie ten einde is en dan komt het eventuele gedrag van een UA dat
>> een session cookie ophoud te bestaan als het domein wordt verlaten
>> mooi uit.

> Ik kan me wel wat dingen voorstellen die misgaan met zo'n browser,
> zoals single sign-on applicatie die tussen domeinen werken. Heb je
> een voorbeeld van zo'n UA ?

Ik geloof dat ik beter had gezegd 'het zou zelfs zomaar zo kunnen zijn'
want nu blijkt "eventueel" te laten denken dat er letterlijk ernstig
rekening moet worden gehouden met dat wat Erick nu juist af wil dwingen:
het verdwijnende koekje. Spreekt voor zich dat er met koekjes genoeg mis
kan gaan (geen RFC verplicht een UA mee te werken. Ik neem overigens niet
aan dat je op 'Cookie Sharing' doelt maar gewoon op het her-betreden van
een domein - "A user agent SHOULD make every attempt to prevent the
sharing of session information between hosts that are in different
domains.")

WD

[Erick T. Barkhuis]

Warden Dave:
> "Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> > Warden Dave:
>
> >> ...en dan komt het eventuele gedrag van een UA dat een session
> >> cookie ophoud te bestaan als het domein wordt verlaten mooi uit.
>
> > Hee, dat wist ik niet.
>
> Let op dat er staat 'eventuele gedrag'

Oh ja.

> > Echt?
> > Ik ga dat eens proberen....dankjewel.
> >
> > [...voert test uit...]
>
> Eh, welke UA is hier de toetssteen?

Firefox 1.06 en 1.5
Maar ik wil ook best K-Meleon de sporen geven.


> > Mijn browser weet ook niet dat dat zo moet.
>
> Niemand zei dat 't zo /moet/

Da's waar, WD.
Ik was even blij met een dooie mus die ik zelf als Fata Morgana in de
dakgoot had gezet. :-)


--
Erick

"Verkoop geen lariekoek. Ik duld geen concurrentie." - N. van der Wijst

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:

> Ik was even blij met een dooie mus die ik zelf als Fata Morgana in
> de dakgoot had gezet. :-)

Nu ik even kijk naar gedane voorstellen/uitspraken van gisteren blijkt bij
kritische beschouwing nog 1 half-mooie zwaan 1 dooie mus.
Proefondervindelijk blijkt met groot gemak van de ene (winkel)pagina naar
de andere te kunnen worden gewandeld zonder dat 't met client-side script
waar te nemen is. Dan vuren events als unload af en je hebt er geen weet
van waar je gaat... [Misschien moet je bijv. toch alle waar via het
populaire XMLHttpRequest Object uitstallen onder 1 URL als dit soort
kleine hoofdbrekens (geen session cookies per tab - in sommige UAs) echt
Grote problemen vormt...]

WD

[Warden Dave]

"Warden Dave" <warden_dave@mnsys.invalid> wrote:

> Misschien moet je bijv. toch alle waar via het populaire
> XMLHttpRequest Object uitstallen onder 1 URL als dit
> soort kleine hoofdbrekens (geen session cookies per tab - in sommige
> UAs) echt Grote problemen vormt...

+ Kleine herhaling: 'een' ID propageren (vanaf het punt waar het winkelen
echt begonnen is) lost, ondanks schaduwzijden, hier ook wel iets op...

WD

[Mark van Ketel]

On 18-9-2006 18:40, Erick T. Barkhuis wrote:
>
> De vraag in het kort:
> hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
> een tabblad - maar niet de browser - sluit?
>

Volgens mij werkt dit al zolang als ik me kan herinneren (iig bij
Netscape/Mozilla en soortgelijke producten), en niet alleen bij tabs,
maar ook gewoon bij windows. Zolang er minimaal 1 window open is bestaat
de sessie (als die geen exp.date/time heeft)

Ik zie het probleem dan ook niet zo. Ik neem aan dat er ook een functie
bestaat: "kieper het mandje geheel leeg, want ik wil opnieuw beginnen"?

Mark

--
weblog : http://www.masadsign.nl/logout/

[Erick T. Barkhuis]

Mark van Ketel:
> On 18-9-2006 18:40, Erick T. Barkhuis wrote:
> >
> > De vraag in het kort:
> > hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
> > een tabblad - maar niet de browser - sluit?
> >
>
> Volgens mij werkt dit al zolang als ik me kan herinneren

Dat zou zomaar kunnen. Ik weet ook niet anders.

> Ik zie het probleem dan ook niet zo.

Dan heb ik misschien de situatie nog steeds niet goed uitgelegd.

> Ik neem aan dat er ook een functie bestaat: "kieper het mandje
> geheel leeg, want ik wil opnieuw beginnen"?

Waarom neem je dat aan? Ik dacht niet dat ik de indruk had gewekt dat
zo'n knopje voorhanden is.


--
Erick

"We're going to turn this team around 360 degrees." - Jason Kidd

[Mark van Ketel]

On 19-9-2006 12:44, Erick T. Barkhuis wrote:
> Mark van Ketel:
>> On 18-9-2006 18:40, Erick T. Barkhuis wrote:
>>> De vraag in het kort:
>>> hoe kun je met PHP een $_SESSION-array leegmaken wanneer de sitebezoeker
>>> een tabblad - maar niet de browser - sluit?
>>>
>> Volgens mij werkt dit al zolang als ik me kan herinneren
>
> Dat zou zomaar kunnen. Ik weet ook niet anders.
>
>> Ik zie het probleem dan ook niet zo.
>
> Dan heb ik misschien de situatie nog steeds niet goed uitgelegd.
>
>> Ik neem aan dat er ook een functie bestaat: "kieper het mandje
>> geheel leeg, want ik wil opnieuw beginnen"?
>
> Waarom neem je dat aan? Ik dacht niet dat ik de indruk had gewekt dat
> zo'n knopje voorhanden is.
>
>

Omdat met het mandje legen het 'probleem' m.i. opgelost is.

Mark

--
weblog : http://www.masadsign.nl/logout/

[Erick T. Barkhuis]

Warden Dave:
> "Warden Dave" <warden_dave@mnsys.invalid> wrote:
>
> > Misschien moet je bijv. toch alle waar via het populaire
> > XMLHttpRequest Object uitstallen onder 1 URL als dit
> > soort kleine hoofdbrekens (geen session cookies per tab - in sommige
> > UAs) echt Grote problemen vormt...
>
> + Kleine herhaling: 'een' ID propageren (vanaf het punt waar het winkelen
> echt begonnen is) lost, ondanks schaduwzijden, hier ook wel iets op...

Ik waardeer je suggesties allemaal, Deef. En ik denk ze zelfs te
begrijpen.
Waar ik wat tegenaan hik is het moeten aanpassen van Erg Veel (nu nog)
statische html-pagina's voor het propageren van die ID en/of het meer
dynamisch binnenhalen van de uitstalling. Het uitvragen van de Refer[r]er
zit in dezelfde categorie.

Zoals al eerder gezegd: ik had zo gehoopt dat er een mogelijkheid zou
bestaan de browser aan het verstand te peuteren dat de sessie moet worden
beeindigd bij het sluiten van een tab.
Kennelijk bestaat die mogelijkheid niet, en zou het met de komende
Session Managers (die het bookmarken van een pagina inclusief de sessie-
variabelen mogelijk maken) wel eens nog erger kunnen worden.

--
Erick

"Voor een grotere kans op lawaai kun je maar beter /ook/ EMBED naast
OBJECT gebruiken" - Warden Dave in niwo

[Warden Dave]

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> Warden Dave:

>> + Kleine herhaling: 'een' ID propageren (vanaf het punt waar het
>> winkelen echt begonnen is) lost, ondanks schaduwzijden, hier ook
>> wel iets op...

> Ik waardeer je suggesties allemaal, Deef. En ik denk ze zelfs te
> begrijpen.
> Waar ik wat tegenaan hik is het moeten aanpassen van Erg Veel (nu
> nog) statische html-pagina's voor het propageren van die ID en/of
> het meer dynamisch binnenhalen van de uitstalling. Het uitvragen
> van de Refer[r]er zit in dezelfde categorie.

Je kunt dit soort (relatief) kleine hoofdbrekens voor het moment
natuurlijk ook even opzij zetten.

> Zoals al eerder gezegd: ik had zo gehoopt dat er een mogelijkheid
> zou bestaan de browser aan het verstand te peuteren dat de sessie
> moet worden beeindigd bij het sluiten van een tab.

Tsja, ik poogde (toegegeven, wat onhandig) al aan te duiden dat
'de' browser in die koekie- & tab-kwestie een wat wankel begrip is
(ook door gebrek aan gedragsvoorschriften) dus als bijv. de ene
browser straks wel per-tab koekjes lust en de ander niet moet je
niet vreemd opkijken. Een browser zou ook kunnen besluiten dat een
koekje weg kan als alle 'bijbehorende' tabs gesloten worden etc.

> Kennelijk bestaat die mogelijkheid niet, en zou het met de
> komende Session Managers (die het bookmarken van een pagina
> inclusief de sessievariabelen mogelijk maken) wel eens nog erger
> kunnen worden.

Zekers, dat kan. Maar bij gebruik van koekjes/IDs met houdbaarheids-
datum sta je ook weer niet geheel machteloos.

WD

[Erick T. Barkhuis]

Warden Dave:

> Je kunt dit soort (relatief) kleine hoofdbrekens voor het moment
> natuurlijk ook even opzij zetten.

Och, telkens wanneer je je Grootste Probleem oplost, blijft het Grootste
Probleem over. Misschien moet ik me ermee gelukkig prijzen dat dit
momenteel mijn Grootste Probleem is, dat ik graag wil oplossen.

> Maar bij gebruik van koekjes/IDs met houdbaarheids-
> datum sta je ook weer niet geheel machteloos.

Da's waar.

Het 'knopje van Mark' is ook een mogelijkheid om de problemen weliswaar
niet te voorkomen, maar in elk geval achteraf door de bezoeker te laten
herstellen.
Ik ben daar nog niet helemaal gelukkig mee, maar als noodverband is het
wellicht bruikbaar.

Een ieder hartelijk dank voor het meedenken, en voor de suggesties en
aanwijzingen.

--
Erick