[ASP] Sessions om pass op te slaan

[Verwijderd]

Ik ben bezig met een forum te schrijven, nu wil ik dat als een user een keer is ingelogd dat hij dat niet telkens opnieuw hoeft te doen. Nu heb ik het met sessions opgelosd. Het probleem hierbij is dat je telkens als je je browser afsluit opnieuw moet inloggen.

Wat zou de beste oplossing zijn om te zorgen dat de sessie in stand blijft als de browser wordt afgesloten?

[gorgi_19]

Het gebruik van cookies en hier een wachtwoord in opslaan.

[Battle Bunny]

Op woensdag 03 juli 2002 22:06 schreef gorgi_19 het volgende:
Het gebruik van cookies en hier een wachtwoord in opslaan.

Volgens mij is het een klein beetje de bedoeling om sessions te gebruiken i.p.v. die malle cookies.

[gorgi_19]

Sessions = cookies op server, gekoppeld aan SessionID. Dus: steeds opnieuw inloggen.

Wil de user niet, dus blijft er niets anders dan cookies op de client over.

[Verwijderd]

Uhh, hoe lost dit forum het dan op? In mijn cookies staat nu ook een sessionid nummertje?
Kan php dat gewoon beter dan ASP?

[Pogostokje]

Wat zou de beste oplossing zijn om te zorgen dat de sessie in stand blijft als de browser wordt afgesloten?

Een sessie blijft per definitie niet overeind, die heeft (gelukkig!) een timeout. Anders zou de server op een gegeven moment onderuit gaan wegens geheugengebrek enzo.

Als je een cookie op de client plaatst, met desnoods alleen een username, ben je klaar. Zo doen al die websites dat.
Een alternatief is met vaste IP adressen werken en die dan authenticaten, maar waarschijnlijk hebben jouw bezoekers die niet.

[Battle Bunny]

Gebruiken de bekende PHP fora dan een ander "soort" sessions dan ASP? Als je de cookies mag geloven die GoT zet, heeft GoT wel een sessie die niet expired (cookie expires op xxx 2003).

Kan dit alleen in PHP, of is dit een compleet andere techniek / aanpak?

[.GoO]

Op woensdag 03 juli 2002 22:35 schreef Battle_Bunny het volgende:
Gebruiken de bekende PHP fora dan een ander "soort" sessions dan ASP? Als je de cookies mag geloven die GoT zet, heeft GoT wel een sessie die niet expired (cookie expires op xxx 2003).

Kan dit alleen in PHP, of is dit een compleet andere techniek / aanpak?

Je kan bij ASP toch ook gewoon een cookie maken en dan de tijd zetten wanneer ie expires?? Ik zie het probleem niet.. Natuurlijk moeten mensen wel cookies enabled hebben, maar dat blijf je houden..

[Gert]

Sessie != cookie.

[Battle Bunny]

Je kan bij ASP toch ook gewoon een cookie maken en dan de tijd zetten wanneer ie expires?? Ik zie het probleem niet.. Natuurlijk moeten mensen wel cookies enabled hebben, maar dat blijf je houden..

Dat kan, ja. Maar voor zover mij bekent, kan dit niet met de cookie die gezet word door IIS wanneer 'ie een nieuwe sessie start.

Sessie != cookie.

Vogel != Vliegtuig

[Bas_f]

Een sessie variable is een variable die door de server wordt onthouden. Zowel in ASP als in PHP.
De server kan dit onthouden dmv. een client-cookie met een unieke ID. Kortom: Als je Sessie variable gebruikt krijgt de client altijd een cookie met daarin 1 variable: je unieke ID.
Dus wanneer je je browser afsluit en opnieuw naar de betreffende site gaat krijg je een nieuw uniek ID en ben je je sessie variable kwijt.

Wat je dus doet, je maakt een cookie en daarin zet je bijv. je database userID of username. Of allebei, nog veiliger!

In de regel geldt: PHP is altijd beter dan ASP, maar in dit geval kan ASP het net zo goed.

[Pogostokje]

In de regel geldt: PHP is altijd beter dan ASP

Typische opmerking in de richting van 'PC is beter dan MAC' en 'Linux is beter dan Windows'.

Het hangt er gewoon vanaf wat je wil wat het meest geschikt is. Beide zijn gewoon goed en doen over het algemeen niet voor elkaar onder.
De voorkeur voor de programmeur telt denk ik het zwaarste.

[Verwijderd]

Op woensdag 03 juli 2002 22:58 schreef Bas_f het volgende:
Een sessie variable is een variable die door de server wordt onthouden. Zowel in ASP als in PHP.
De server kan dit onthouden dmv. een client-cookie met een unieke ID. Kortom: Als je Sessie variable gebruikt krijgt de client altijd een cookie met daarin 1 variable: je unieke ID.
Dus wanneer je je browser afsluit en opnieuw naar de betreffende site gaat krijg je een nieuw uniek ID en ben je je sessie variable kwijt.

Wat je dus doet, je maakt een cookie en daarin zet je bijv. je database userID of username. Of allebei, nog veiliger!

In de regel geldt: PHP is altijd beter dan ASP, maar in dit geval kan ASP het net zo goed.

maar waarom is de duration van het sessionid wat ik van GoT krijg dan tot 2003 en niet tot "end of session"?

en als ik dus een cookie maak met jouw userid en jouw name ben ik dus ingelogd als jouw?

[Bas_f]

Op woensdag 03 juli 2002 23:01 schreef Pogostokje het volgende:

Typische opmerking in de richting van 'PC is beter dan MAC' en 'Linux is beter dan Windows'.

Het hangt er gewoon vanaf wat je wil wat het meest geschikt is. Beide zijn gewoon goed en doen over het algemeen niet voor elkaar onder.
De voorkeur voor de programmeur telt denk ik het zwaarste.

Beetje een terugkerende discussie, maar kijk eens naar de mogelijkheden, stabiliteit en kosten van PHP, en dan naar ASP. Dan is voor mij de keuze snel gemaakt.

[Verwijderd]

Op woensdag 03 juli 2002 23:06 schreef Bas_f het volgende:

[..]

Beetje een terugkerende discussie, maar kijk eens naar de mogelijkheden, stabiliteit en kosten van PHP, en dan naar ASP. Dan is voor mij de keuze snel gemaakt.

Ik ben niet echt op zoek naar een PHP vs. ASP discussie, sorry

[Bas_f]

Op woensdag 03 juli 2002 23:05 schreef Appelmeloen het volgende:

[..]

maar waarom is de duration van het sessionid wat ik van GoT krijg dan tot 2003 en niet tot "end of session"?

en als ik dus een cookie maak met jouw userid en jouw name ben ik dus ingelogd als jouw?

Omdat de server de timeout bepaald van de sessie variable, niet de client-cookie.

En als 2e: Als je een cookie maakt met mijn userid en naam ben je idd. ingelogd als mij. Voor GoT is er een betere beveiliging gebruikt (mag ik hopen), maar je kunt allerlei constructie's bedenken om 't veilig te maken. (Denk bijv. aan een unieke code die wordt aangemaakt en iedere keer wordt veranderd)

[Soultaker]

Ik ken ASP niet, maar waarom kan iemand die dat wel doet (en die blijkbaar ook aan deze thread deelneemt) niet uitleggen hoe het ASP sessie mechanisme werkt?

Het lijkt me dat er in ieder geval ergens een sessie ID gebruikt wordt. Die kun je dus zonder problemen in een persistente cookie stoppen (elke keer meesturen in de query-string, wat in PHP ook kan, is toch een beetje een beunoplossing). Wat is precies het probleem?

Als het niet mogelijk is om de huidige sessie ID te zien en in te stellen, dan ben ik benieuwd hoe het wél werkt. Aan een discussie of PHP beter is dan ASP of omgekeerd heeft de topicstarter niet zoveel.

[Soultaker]

Op woensdag 03 juli 2002 23:09 schreef Bas_f het volgende:
En als 2e: Als je een cookie maakt met mijn userid en naam ben je idd. ingelogd als mij. Voor GoT is er een betere beveiliging gebruikt (mag ik hopen), maar je kunt allerlei constructie's bedenken om 't veilig te maken. (Denk bijv. aan een unieke code die wordt aangemaakt en iedere keer wordt veranderd)

Nee hoor, dat werkt op GoT precies zo en dat is veilig. De browser slaat het cookie op per gebruiker. Als een gebruiker er voor kiest om z'n inloggegevens permanent op te slaan én niet uitlogd (of alle gebruikers hetzelfde account gebruiken) dan is het logisch dat een andere gebruiker onder zijn account kan werken.

[Bas_f]

Op woensdag 03 juli 2002 23:10 schreef Soultaker het volgende:
Ik ken ASP niet, maar waarom kan iemand die dat wel doet (en die blijkbaar ook aan deze thread deelneemt) niet uitleggen hoe het ASP sessie mechanisme werkt?

Zie mijn eerste post in deze thread...

[Battle Bunny]

Het lijkt me dat er in ieder geval ergens een sessie ID gebruikt wordt. Die kun je dus zonder problemen in een persistente cookie stoppen (elke keer meesturen in de query-string, wat in PHP ook kan, is toch een beetje een beunoplossing). Wat is precies het probleem?

Dit klinkt alsof de client (i.e.: de browser) degene is die de sessie killed (omdat de cookie zo staat)? Of niet? Een cookie lijkt me weinig nut hebben als de sessie server-side foetsie is.

[Bas_f]

Is er behoefte aan een uitgebreide uitleg over hoe sessie variablen en cookies werken? Zo ja, dan schrijf ik er ff eentje.

[Battle Bunny]

Is er behoefte aan een uitgebreide uitleg over hoe sessie variablen en cookies werken? Zo ja, dan schrijf ik er ff eentje.

Zou erg aardig zijn. De documentatie is wat dit betreft niet echt op en top (of je moet een MS boek kopen). En ik heb het idee dat ik en Appelmeloen een paar ideeen verkeerd hebben.

[Verwijderd]

Op woensdag 03 juli 2002 23:13 schreef Soultaker het volgende:

[..]

Nee hoor, dat werkt op GoT precies zo en dat is veilig. De browser slaat het cookie op per gebruiker. Als een gebruiker er voor kiest om z'n inloggegevens permanent op te slaan én niet uitlogd (of alle gebruikers hetzelfde account gebruiken) dan is het logisch dat een andere gebruiker onder zijn account kan werken.

Als ik zo eens door mijn cookies heen ga, is de waarde van mijn cookie sessid van GoT gelijk aan het id wat je meegeeft aan profile.php.
Aangezien een cookie op de client staat en dus aan te passen is, lijkt het me niet helemaal veilig om alleen het id op te slaan.
GoT moet dus naast sessid ook nog een andere manier hebben om te kijken of je rechtmatig bent ingelogd

[Pogostokje]

Oke, de ASP uitleg (al staat het hier al tussen de regels uitgelegd):

Bij ASP heb je sessions. De server kent een uniek SessionID toe en stuurt deze in een speciaal soort cookie naar de client. Bij elk verzoek stuurt de client dat ding automatisch mee en zo blijft de server weten welke client het betreft. Op de server kan je vervolgens allerlei variabelen vullen die horen bij deze sessie, zoals username. Deze zijn vanuit ASP gewoon te gebruiken als normale variabelen, net zoals normale cookies dat ook zijn.

Als de server na xx minuten (standaard: 20 minuten) een bepaalde sessie niet meer gebruikt heeft gaat de server ervan uit dat de client niet meer op de website zit en gooit hij de sessievariabelen weg en 'vergeet' hij de sessionID. Een client kan dan dus geen aanspraak meer maken op dat ID en zal, als hij per ongeluk toch nog op de website zat, een nieuw ID krijgen. Die timeout is instelbaar, voor alle sessies tegelijk of vanuit een ASP script zelfs per sessie een verschillende.

Dit kan je dus niet gebruiken om username/password voor langere tijd op te slaan. De sessie verloopt immers na een aantal minuten. Deze sessies worden opgeslagen in het geheugen van de webserver dus het is geen optie de timeout naar 3 jaar te zetten: je server zou zonder geheugen komen te ziiten en mocht er een keer de webserver herstart worden dan is alle info weg.
Je kan 'normale' cookies gebruiken (zoals GOT dat ook doet) om iets van een authenticatie bij de client achter te laten, met een timeout van 3 jaar of nog langer. Die cookies kosten een paar bytes diskruimte bij de client, daar heeft de server geen last van. Als de client op de website komt wordt dat cookie gebruikt om een gebruiker bv. automatisch in te loggen. Ik weet niet hoe GOT dat daarna afhandelt, afgezien van dat GOT geen ASP gebruik.

//edit: ik was hier aan begonnen voor iemand aanbood een complete uitleg te schrijven. Die posting had ik dus nog niet gelezen en dit is dan ook niet bedoelt om dat te vervangen ofzo hoor.

[Soultaker]

Op woensdag 03 juli 2002 23:13 schreef Bas_f het volgende:
Zie mijn eerste post in deze thread...

Ok, die heb ik gelezen.

WAT is dan het grote probleem om die sessie ID in een PERSISTENTE cookie (die dus de levensduur van je browser overspant) te zetten?

Dit kan je dus niet gebruiken om username/password voor langere tijd op te slaan. De sessie verloopt immers na een aantal minuten. Deze sessies worden opgeslagen in het geheugen van de webserver dus het is geen optie de timeout naar 3 jaar te zetten: je server zou zonder geheugen komen te ziiten en mocht er een keer de webserver herstart worden dan is alle info weg.

Aha, ok. Dat dus.

Ik weet niet of ASP kan serializen a la PHP? In dat geval kun je in tien regels code je eigen (persistente) sessiemechanisme maken, dat de gegevens per gebruiker in een of andere directory opslaat.

[Pogostokje]

WAT is dan het grote probleem om die sessie ID in een PERSISTENTE cookie (die dus de levensduur van je browser overspant) te zetten?

Die cookie zetten bij de client is geen probleem. Maar die sessie ID vervalt na xx minuten aan de serverkant.

[gorgi_19]

Ik ken ASP niet, maar waarom kan iemand die dat wel doet (en die blijkbaar ook aan deze thread deelneemt) niet uitleggen hoe het ASP sessie mechanisme werkt?

Gorgi voelt zich erg aangesproken en gaat nu een poging wagen om het verhaal duidelijk uit te leggen.

Een cookie is een bestand met een bepaalde geldigheid en een bepaalde inhoud, wat op de client geplaatst worden. Onder andere kan hier een gebruikersnaam in worden opgeslagen, al dan niet gecodeerd (bv. MD5). Door middel van een cookie van een client zich identificeren bij een website.

Een sessie werkt anders. Zodra een client een website bezoekt, wordt op de server een sessie-id aangemaakt om de client te kunnen 'identificeren', nog niet door middel van een wachtwoord, maar alleen: welke pagina moet ik waarheen sturen; op deze manier kunnen bijvoorbeeld klikpaden achterhaald worden, maar dit terzijde.
Ook kan het voorkomen dat bepaalde informatie, zoals de username of authenticatiestatus, op de server opgeslagen moeten worden. Dit wordt gedaan in een Sessie-variabele (of door middel van het Session-object, om in ASP-termen te spreken). Een Sessie-variabele is dus een soort cookie op de server. Serverside cookies (sessions) hebben normaal gesproken een bestaansrecht van 20 minuten; na 20 minuten van inactiviteit is de server 'vergeten' wie je bent en wordt een nieuwe sessionID voor je aangemaakt. Door de nieuwe sessionID vervalt ook de koppeling met het cookie.

Dus: iedere keer een website bezoeken = iedere keer een nieuwe sessionID = een nieuwe session. Data in oude sessions is dus niet terug te halen en gebruikersgebonden.

Zo het verhaal een stuk duidelijker?

edit:
darn, zo te zien waren er een hele hoop mensen mij voor..

[Pogostokje]

Ik weet niet of ASP kan serializen a la PHP? In dat geval kun je in tien regels code je eigen (persistente) sessiemechanisme maken, dat de gegevens per gebruiker in een of andere directory opslaat.

Ik ken die term alleen vanuit mijn databases achtergrond, maar dat lijkt me niet van toepassing hier.
Wat bedoel je precies met serializen?

[Battle Bunny]

Bedankt voor deze mooie uitleg. Helaas betekent dit dus dat je zelf een table zal moeten maken met een random Id, Userid, etc en die twee in cookie moet mikken. Meer werk, maar het werkt wel!

[Bas_f]

Op woensdag 03 juli 2002 23:22 schreef Pogostokje het volgende:
//edit: ik was hier aan begonnen voor iemand aanbood een complete uitleg te schrijven. Die posting had ik dus nog niet gelezen en dit is dan ook niet bedoelt om dat te vervangen ofzo hoor.

Mooie uitleg!

Zo werkt 't in PHP ook, op 't verschil na dat PHP de sessies in een TEMP dir gooit in 1 file per client.

Additioneel:
Er komt dus geen van de sessie variablen bij de client terecht! Alleen een uniek ID!

[.GoO]

Wat is de maximale expire tijd van een session die in te stellen is??

[Bas_f]

Op woensdag 03 juli 2002 23:33 schreef devv05 het volgende:
Wat is de maximale expire tijd van een session die in te stellen is??

Ik vermoed dat dat bijna unlimited is. Alleen dat is niet aan te raden omdat je server dan ALLE variable onthoud en langzaam dichtslipt.

[edit]
24 uur dus - Pogostokje

[Pogostokje]

Wat is de maximale expire tijd van een session die in te stellen is??

24 uur.
"The Session.TimeOut has a maximum of 24 hours (1440 minutes). Sessions variables are no longer valid past this time." - Microsoft

Maar de vraag is of je dat wel wil ... want het word dus in het GEHEUGEN van de server opgeslagen allemaal. Zeker als een server meerdere websites host dan zal je vragen krijgen van je serverbeheerder.
Sessies kosten nl. best wat geheugenruimte. Zeker als je, wat echt niet de bedoeling is maar helaas wel kan, binary data gaat opslaan in een sessie, zoals usericon's en dat soort spul. Dat vreet geheugen.

[Pogostokje]

[edit]
24 uur dus - Pogostokje

Had ik ook maar even snel opgezocht met google hoor.

[Soultaker]

Op woensdag 03 juli 2002 23:28 schreef Pogostokje het volgende:
Wat bedoel je precies met serializen?

Serializen is het omzetten van allerlei complexe datastructuren naar een simpele datastroom (een serie van domme bytes dus) en weer terug (unserializen).

Het voordeel hiervan is dat je in je code gewoon alle gegevens in je variabelen kan stoppen en dat je op 't eind al die variabelen in een sessie array stopt (dat moet toch al, neem ik aan). Deze array serialize je naar binaire data, die je in een bestand of een database kan zetten, zonder dat je je zorgen hoeft te maken over de precise representatie. Op een later moment kun je de oorspronkelijke array met al z'n (eventueel complexe) inhoud dan weer uitlezen met een unserialize operatie.

[Pogostokje]

Serializen is het omzetten van allerlei complexe datastructuren naar een simpele datastroom (een serie van domme bytes dus) en weer terug (unserializen).
[...]

Hm, interessant zeg.
Dus het is eigenlijk een beetje creatief knippen&plakken met strings en andere data die je wil bewaren en deze 'gecodeerde' informatie opslaan op een plek waar het behouden blijft. Zo kan je je sessie als het ware 'opslaan'.
Ik zie niet waarom dat onder ASP niet kan, het is een kwestie van de juiste bewerkingen uitvoeren met je data.
Je kan het zo ingewikkeld maken als je zelf wil natuurlijk, maar het idee staat mij zeker aan!

[Soultaker]

Op woensdag 03 juli 2002 23:48 schreef Pogostokje het volgende:
Dus het is eigenlijk een beetje creatief knippen&plakken met strings en andere data die je wil bewaren en deze 'gecodeerde' informatie opslaan op een plek waar het behouden blijft. Zo kan je je sessie als het ware 'opslaan'.

Dat is inderdaad het idee. Het mooie is dat als je een binaire representatie van je data hebt, je je data overal kwijt kan, want alles kan binaire data opslaan. Dit is dus ook een ideale manier om variabelen over een netwerkverbinding te sturen en dergelijke.

Het voordeel van serialization in PHP is dat het in de standardlibrary zelf is geimplementeert en je als gebruiker (in de meeste gevallen) dus helemaal niets zelf hoeft te schrijven. Als je het zelf moet maken moet je aan veel dingen 'denken'. Ik kan me echter nauwelijks voorstellen dat iemand het niet al eens gemaakt heeft voor ASP.