[VB.NET / ASP.NET] Sessies opslaan in niet-MSSQL server

[Verwijderd]

Ik ben een ASP-applicatie aan het maken.
De ASP-applicatie moet kunnen werken met Firebird en MS SQL Server ().
Het is de bedoeling dat de sessie status in de database opgeslagen dient te worden, omdat ik later wil kunnen achterhalen wie er bijvoorbeeld ingelogd is, naam, inlogtijd, etc.

In ASP.NET heb je vier methodes om te gaan met sessies: Inproc, StateServer, SqlServer en Off.

De SqlServer-optie is uiteraard geoptimaliseerd voor MS SQL server.

Hoe pak ik dit nu aan voor Firebird (of wat mij betreft als voorbeeld een ander DBMS)?

Er is hier blijkbaar weinig informatie over...
Hierzo een soortgelijk probleem zonder antwoord.

[whoami]

Hmmm, je zult een DB moeten aanmaken op je DBMS denk ik, die een bepaalde naam heeft, en die bepaalde tabellen en evt stored procedures bevat.
Ik vraag me trouwens sterk af of het zomaar mogelijk is, om session state in een niet SQL Server / MSDE databank op te slaan.

Je kan natuurlijk ook nog altijd een 'State Server' gebruiken om de session state in op te slaan.
Je gebruikt dan wel geen db, maar het is een andere optie om session state op te slaan in webfarms.

[ Voor 28% gewijzigd door whoami op 17-03-2004 22:11 ]

[gorgi_19]

Erhm.. Wat wil je nu doen? Wat is de reden om sessies op te slaan? Voor de session state? Of voor tracking?

Je noemt de methodiek om sessies op te slaan, maar in je eerste alinea geef je een tracking reden.

[Verwijderd]

gorgi_19 schreef op 17 maart 2004 @ 22:14:
Erhm.. Wat wil je nu doen? Wat is de reden om sessies op te slaan? Voor de session state? Of voor tracking?

Je noemt de methodiek om sessies op te slaan, maar in je eerste alinea geef je een tracking reden.

In eerste instantie alleen voor de tracking.
Zoals wie er ingelogd zijn, de naam, inlogtijd, etc. Ik moet zelf een query op deze gegevens los kunnen laten.
De overige gegevens van de sessies zijn voor mij niet direkt van belang. Ze moeten uiteraard wel ergens opgeslagen worden en beschikbaar zijn voor ASP.NET.

Het gaat maar om één DBMS die per applicatie gebruikt wordt. Van een database cluster ofzo is dus geen sprake.

[ Voor 10% gewijzigd door Verwijderd op 17-03-2004 22:23 ]

[whoami]

Verwijderd schreef op 17 maart 2004 @ 22:21:
[...]

In eerste instantie alleen voor de tracking.
Zoals wie er ingelogd zijn, de naam, inlogtijd. Ik moet zelf een query op deze gegevens los kunnen laten.
De overige gegevens van de sessies zijn voor mij niet direkt van belang. Ze moeten uiteraard wel ergens opgeslagen worden en beschikbaar zijn voor ASP.NET.

Dan kan je het toch ook anders oplossen? Bij het inloggen doe je dan gewoon een insert oid in een of andere log-tabel: wie er inlogged, op welke datum, tijdstip, ip, etc....

[gorgi_19]

Verwijderd schreef op 17 maart 2004 @ 22:21:
[...]

In eerste instantie alleen voor de tracking.
Zoals wie er ingelogd zijn, de naam, inlogtijd, etc. Ik moet zelf een query op deze gegevens los kunnen laten.
De overige gegevens van de sessies zijn voor mij niet direkt van belang. Ze moeten uiteraard wel ergens opgeslagen worden en beschikbaar zijn voor ASP.NET.

Dan moet je imho helemaal niet met SessionState willen gaan werken, maar eens kijken naar je Global.Asax . Ik geloof je dat ook iets van een Session_OnBegin event hebt (precieze naam moet je even nazoeken) en hier een actie (= insert in database).

Eenvoudiger lijkt me, omdat het met inlogtijd gaat, om het AuthenticateRequest (oid) event te pakken en hierbij de actie te gaan loggen. Althans, ik neem aan dat je niet zelf aan de gang bent met een eigen inlogsysteem op basis van sessies?

Het gaat maar om één DBMS die per applicatie gebruikt wordt. Van een database cluster ofzo is dus geen sprake.

Sessionstate met die 4 methodieken die he noemt heb je helemaal niets mee te maken met je probleem. Sessionstate is pas van belang is als je met webfarms aan de gang gaat. 't heeft ook niets te maken met een databasecluster.

[ Voor 19% gewijzigd door gorgi_19 op 17-03-2004 22:28 ]

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 22:24:
[...]

Dan moet je imho helemaal niet met SessionState willen gaan werken, maar eens kijken naar je Global.Asax . Ik geloof je dat ook iets van een Session_OnBegin event hebt (precieze naam moet je even nazoeken) en hier een actie (= insert in database).

Eenvoudiger lijkt me, omdat het met inlogtijd gaat, om het AuthenticateRequest (oid) event te pakken en hierbij de actie te gaan loggen. Althans, ik neem aan dat je niet zelf aan de gang bent met een inlogsysteem en sessies?

Ik denk dat je best een record insert bij het inloggen, als bij een SessionBegin. Een user kan nl. de site verlaten zonder uit te loggen, en later 'm terug bezoeken, maar dan hoeft ie niet in te loggen, want hij is al ingelogged.
Wordt de AuthenticateRequest trouwens niet voor iedere request uitgevoerd, ipv enkel bij het inloggen?

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 22:24:
[...]
Sessionstate is pas van belang is als je met webfarms aan de gang gaat. 't heeft ook niets te maken met een databasecluster.

Je bedoelt hier waarschijnlijk dat Session State opslaan in een Sql Server DB of op een state server enkel van belang is als je met webfarms aan de gang gaat?

[gorgi_19]

whoami schreef op 17 maart 2004 @ 22:29:
[...]

Ik denk dat je best een record insert bij het inloggen, als bij een SessionBegin. Een user kan nl. de site verlaten zonder uit te loggen, en later 'm terug bezoeken, maar dan hoeft ie niet in te loggen, want hij is al ingelogged.
Wordt de AuthenticateRequest trouwens niet voor iedere request uitgevoerd, ipv enkel bij het inloggen?

Volgens mij niet; wat zou anders het nut zijn van BeginRequest? Maar als het wel het geval is, kan j ehet controleren met User.Identity.IsAuthenticated (oid). Als deze waarde false is, is de user niet geauthenticeerd. Je maakt in principe een extra aanvulling op de Role Based Security van MS.

[gorgi_19]

whoami schreef op 17 maart 2004 @ 22:30:
[...]



Je bedoelt hier waarschijnlijk dat Session State opslaan in een Sql Server DB of op een state server enkel van belang is als je met webfarms aan de gang gaat?

Erhm.. Ja.. Als je met webfarms gaat klooien, moet je imho pas aan Sessionstate veranderingen gaan denken buiten InProc. Nu weet ik alleen niet of het al gaat bokken met WebGardens. 'k heb er iig nog nooit problemen mee gehad.

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 22:30:
[...]

Volgens mij niet; wat zou anders het nut zijn van BeginRequest? Maar als het wel het geval is, kan j ehet controleren met User.Identity.IsAuthenticated (oid). Als deze waarde false is, is de user niet geauthenticeerd. Je maakt in principe een extra aanvulling op de Role Based Security van MS.

Ik weet het ook niet zeker hoor, 't is nl. al een tijd geleden dat ik nog wat met ASP.NET gedaan heb.
Er stond me gewoon zo iets bij....

[gorgi_19]

whoami schreef op 17 maart 2004 @ 22:32:
[...]


Ik weet het ook niet zeker hoor, 't is nl. al een tijd geleden dat ik nog wat met ASP.NET gedaan heb.
Er stond me gewoon zo iets bij....

Meest eenvoudige is om gewoon een willekeurige role based security / forms authentication tutorial te pakken en op de plaats van het aanmaken van de authentication ticket nog die update / insert uit te voeren.

[Verwijderd]

gorgi_19 schreef op 17 maart 2004 @ 22:24:
[...]
Eenvoudiger lijkt me, omdat het met inlogtijd gaat, om het AuthenticateRequest (oid) event te pakken en hierbij de actie te gaan loggen. Althans, ik neem aan dat je niet zelf aan de gang bent met een eigen inlogsysteem op basis van sessies?

Ik wil juist wel een eigen inlogsysteem gebruiken. Zoiets wordt het denk ik:

pseudo code login:

code:

* inloggen:
DELETE FROM SESSIONS
WHERE (Tijd < (Now-(5 uur)))

if (login-autorisatie = ok) then
begin
  (INSERT INTO SESSIONS (SessionId,...) VALUES (mySessionId, Tijd...)
end;
 
* uitloggen:
if (logout) then
begin
  DELETE FROM SESSIONS WHERE SessionId=mySessionId
end;

Met natuurlijk de nodige controles, etc.

Sessionstate met die 4 methodieken die he noemt heb je helemaal niets mee te maken met je probleem. Sessionstate is pas van belang is als je met webfarms aan de gang gaat. 't heeft ook niets te maken met een databasecluster.

Hmm, dit maakt het een stuk simpelere. Als dat zo is dan mogen ze dit wel beter documenteren en had ik nu meer haar op m'n hoofd.

[gorgi_19]

Waarom gebruik je niet het standaard Role Based Security systeem / methodiek inclusief Forms Authentication?

* gorgi_19 mompelt iets over wiel opnieuw uitvinden enzo...

Hmm, dit maakt het een stuk simpelere. Als dat zo is dan mogen ze dit wel beter documenteren en had ik nu meer haar op m'n hoofd.

Hmmm.. Imho staat dit vrij duidelijk gedocumenteerd?

[ Voor 38% gewijzigd door gorgi_19 op 17-03-2004 22:41 ]

[whoami]

Verwijderd schreef op 17 maart 2004 @ 22:39:
[...]

Ik wil juist wel een eigen inlogsysteem gebruiken.

Waarom wil je het wiel opnieuw uitvinden?
Heb je al eens naar 'forms authentication' gekeken? Zonee, dan moet je dat eerst en vooral maar eens doen.

[Verwijderd]

whoami schreef op 17 maart 2004 @ 22:40:
[...]

Waarom wil je het wiel opnieuw uitvinden?
Heb je al eens naar 'forms authentication' gekeken? Zonee, dan moet je dat eerst en vooral maar eens doen.

Ik ben nog vergeten te vertellen
Dat het nog uitgebreider moet worden. Bijvoorbeeld het aantal maximaal ingelogde gebruikers kunnen beperken, etc.

Ik ga eerst maar eens de mogelijkheden van 'forms authentication' onderzoeken.

[gorgi_19]

Verwijderd schreef op 17 maart 2004 @ 22:43:
[...]

Ik ben nog vergeten te vertellen
Dat het nog uitgebreider moet worden. Bijvoorbeeld het aantal maximaal ingelogde gebruikers kunnen beperken, etc.

Ik ga eerst maar eens de mogelijkheden van 'forms authentication' onderzoeken.

* gorgi_19 ziet nog geen enkel probleem met Forms Authentication? Je houdt het aantal bij in een Application object en telt er bij inloggen eentje bij, bij uitloggen / verlopen eentje af.

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 22:44:
[...]

* gorgi_19 ziet nog geen enkel probleem met Forms Authentication? Je houdt het aantal bij in een Application object en telt er bij inloggen eentje bij, bij uitloggen / verlopen eentje af.

Is dat betrouwbaar? Is het niet beter dat je dat bij / voor het inloggen in de DB zelf gaat gaan checken?

[Verwijderd]

gorgi_19 schreef op 17 maart 2004 @ 22:44:
[...]

* gorgi_19 ziet nog geen enkel probleem met Forms Authentication? Je houdt het aantal bij in een Application object en telt er bij inloggen eentje bij, bij uitloggen / verlopen eentje af.

Bij nader inzien denk ik dat het een combinatie van beide wordt. Een historie van wie wanneer heeft inglogd is namelijk ook wel handig en dit kan alleen in een database opgeslagen worden.

[gorgi_19]

whoami schreef op 17 maart 2004 @ 22:50:
Is dat betrouwbaar? Is het niet beter dat je dat bij / voor het inloggen in de DB zelf gaat gaan checken?

Je zou een lastaction / lastseen kunnen gebruiken als veld in je usercolumn. Iedereen die langer dan 20 minuten niet gezien is, kan je als foetsie beschouwen.

Verder lijkt het me sterk dat het Session_OnEnd oid event niet gefired wordt. Met de huidige ondersteuning van events lijkt me dit geen probleem meer.

Verwijderd schreef op 17 maart 2004 @ 22:50:
[...]

Bij nader inzien denk ik dat het een combinatie van beide wordt. Een historie van wie wanneer heeft inglogd is namelijk ook wel handig en dit kan alleen in een database opgeslagen worden.

Er bestaat alleen wel het gevaar dat bij een verkeerde implementatie je een ontzettend trage querie krijgt.

[ Voor 29% gewijzigd door gorgi_19 op 17-03-2004 22:54 ]

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 22:54:
[...]

Je zou een lastaction / lastseen kunnen gebruiken als veld in je usercolumn. Iedereen die langer dan 20 minuten niet gezien is, kan je als foetsie beschouwen.

Verder lijkt het me sterk dat het Session_OnEnd oid event niet gefired wordt. Met de huidige ondersteuning van events lijkt me dit geen probleem meer.
[...]

Er bestaat alleen wel het gevaar dat bij een verkeerde implementatie je een ontzettend trage querie krijgt.

Ik doel eigenlijk vooral op, wat als de applicatie herstart wordt, door een (interne) fout, wat als de processen gerecycled worden, etc.....
Kan het dan niet zijn dat de application-variables terug geinitialiseerd worden, maar de mensen gewoon ingelogged blijven (ze hebben nl. een authentication ticket op hun pc staan).

[Verwijderd]

gorgi_19 schreef op 17 maart 2004 @ 22:54:
[...]

Je zou een lastaction / lastseen kunnen gebruiken als veld in je usercolumn. Iedereen die langer dan 20 minuten niet gezien is, kan je als foetsie beschouwen.

Verder lijkt het me sterk dat het Session_OnEnd oid event niet gefired wordt. Met de huidige ondersteuning van events lijkt me dit geen probleem meer.
[...]

Er bestaat alleen wel het gevaar dat bij een verkeerde implementatie je een ontzettend trage querie krijgt.

De sessie wordt onmiddelijk weer aangemaakt door ASP.NET en de bijbehorende code, echter men is dan niet meer in de applicatie ingelogd.

[whoami]

Verwijderd schreef op 17 maart 2004 @ 22:56:
[...]

De sessie wordt onmiddelijk weer aangemaakt door ASP.NET en de bijbehorende code, echter men is dan niet meer in de applicatie ingelogd.

Dat snap ik niet.
Als je langer dan inactief bent, dan wordt je sessie gewoon beëindigd.

[gorgi_19]

whoami schreef op 17 maart 2004 @ 22:56:
[...]


Ik doel eigenlijk vooral op, wat als de applicatie herstart wordt, door een (interne) fout, wat als de processen gerecycled worden, etc.....
Kan het dan niet zijn dat de application-variables terug geinitialiseerd worden, maar de mensen gewoon ingelogged blijven (ze hebben nl. een authentication ticket op hun pc staan).

Als je het proces keihard killed dmv task manager, dan ben je je sessie kwijt. Als je een application restart doet, dmv IIS OF dmv het veranderen van je web.config of je bin folder, ben je je sessie kwijt.

Een restart van het wp, door bijvoorbeeld een recycling oid, heeft afaik nog geen gevolgen voor sessies.
Authentication ticket overleeft trouwens gewoon netjes een application restart. Zelfs een wijziging van je web.config.

[whoami]

gorgi_19 schreef op 17 maart 2004 @ 23:01:
[...]
Een restart van het wp, door bijvoorbeeld een recycling oid, heeft afaik nog geen gevolgen voor sessies.
Authentication ticket overleeft trouwens gewoon netjes een application restart. Zelfs een wijziging van je web.config.

Daar doelde ik niet op: je sessies blijven bestaan maar je application variables niet bij een recycle.