[asp/mssql] Een account per user???

[Verwijderd]

Hoi mensen van tweakers,

Ik zit met een klein probleem:

Ik heb een web pagina met een user- administratie, hier gaat alles nog goed, maar hetgeen ik een beetje tegenaan loop is hetvolgende.

Ik wil tegengaan dat er meerdere personen gebruik maken van een account.

Ik heb allerlei dingen zitten overwegen als passwords veranderen op reguliere basis, IP- logging/restricting en misschien het account dicht gooien als iemand er gebruik van maakt.

De eerste vind ik niet echt een optie, IP-logging/restricting is dit ook echter niet.

Weet iemand een goede of betrouwbare manier?

Ik zelf zit te denken aan het actieve account dichtgooien voor inloggen, als de sessie afgesloten wordt voor de user, moet het account ook weer opengezet worden.

Zit ik hiermee in de goede richting, of moet ik aan meer dingen denken?

Ik heb voor mijzelf ook vastgesteld, dat je dan ten tijde van een actieve sessie ingedekt zit;
is de sessie niet actief, dan kunnen andere personen alsnog gebruik maken van dit account.

Please help, want ik zit echt helemaal vast.

[gorgi_19]

Stel je hebt een usertabel
UserID int
Username varchar
Password varchar(32)
SessionID varchar

Als iemand ingelogd is, verander je de sessionID naar de huidige sessionID.

Als iemand op een andere computer inlogt, verschijnt er een nieuw sessionId, andere user wordt vervolgens uitgelogd. Zo forceer je maar 1 gebruiker.

[curry684]

Dit kun je alleen met IP-logging 'enigszins' oplossen. Op gorgi's manier forceer je 1 gebruiker tegelijkertijd maar heb je verder geen controle of er ieder uur een andere langskomt. Daarvoor zul je IP's moeten loggen en foutmarges vaststellen (dus niet meteen account nuken als iemand's IP verandert).

[gorgi_19]

curry684 schreef op 06 juni 2003 @ 13:13:
Dit kun je alleen met IP-logging 'enigszins' oplossen. Op gorgi's manier forceer je 1 gebruiker tegelijkertijd maar heb je verder geen controle of er ieder uur een andere langskomt. Daarvoor zul je IP's moeten loggen en foutmarges vaststellen (dus niet meteen account nuken als iemand's IP verandert).

Waarbij IP-logging imho al bij voorbaat zinloos is; je hebt proxyservers, waar ASP iig helemaal niet dol op is bij het opvragen van IP's.

Maar wat is er mis met mijn methodiek? Je hebt maar 1 gebruiker welke langskomt, 1 gebruiker is ook maar tegelijkertijd actief. Indien een 2e actief wordt, moet de eerste gedwongen uitloggen.

Na een uur is het niet irreeel dat dezelfde gebruiker op een andere weer gaat inloggen.

Ga je de huidige gebruiker vastleggen, dan heb je het probleem dat er bij een session timeout een gebruiker een x- aantal minuten moet wachten voordat hij weer kan inloggen.

[ Voor 12% gewijzigd door gorgi_19 op 06-06-2003 13:22 ]

[Verwijderd]

Ik zit dus zelf ook aan jouw idee te denken gorgi.

Het vastleggen van IPs is dus ook niet echt fijn omdat er idd gebruik gemaakt wordt van users die of via een prox op de pagina komen, of dat dezelfde user vanaf elke willekeurige plek op zijn laptop in probeert te loggen;
hetzij via een andere prox of via een telefoon/wifi/gsm- lijntje.

[Verwijderd]

Zou het ook zo doen.. als je je app voorziet van een logout knopje en users automaties uitlogd in de Session_OnEnd zou je nog kunnen waarschuwen voordat je de sessionid in de database overschrijft: "account is in gebruik, andere user uitloggen?"

[robjanssen]

Maar dan heb je weer het probleem dat de Session_OnEnd niet betrouwbaar is en dat een account dus voor altijd gelockt is.
Een oplossing hiervoor is een UpdateDate gebruiken die bij iedere actie geupdate wordt.
En als DateDiff(UpdateDate, Now) > Session.TimeOut dat er dan weer andere Users in kunnen loggen.

[gorgi_19]

robjanssen schreef op 07 June 2003 @ 09:31:
Maar dan heb je weer het probleem dat de Session_OnEnd niet betrouwbaar is en dat een account dus voor altijd gelockt is.
Een oplossing hiervoor is een UpdateDate gebruiken die bij iedere actie geupdate wordt.
En als DateDiff(UpdateDate, Now) > Session.TimeOut dat er dan weer andere Users in kunnen loggen.

Het nadeel van deze methodiek is dat je, bij een normale session timeout, je met een beetje pech 20 minuten moet wachten voordat je weer opnieuw kan inloggen.

[robjanssen]

Natuurlijk niet je houdt toch ook gewoon ergens bij of er iemand is ingelogd met een BIT bijvoorbeeld, als iemand dan uitlogt via de logout knop zet je dat BIT weer op 0 en mag er weer iemand anders inloggen, bij de Session_OnEnd zet je ook dat BIT op 0.
En als de Session_OnEnd niet is opgetreden dan geldt dat bij DateDiff(UpdateDate, Now) > Session.TimeOut een nieuwe gebruiker toch mag inloggen.

[gorgi_19]

robjanssen schreef op 07 June 2003 @ 10:10:
Natuurlijk niet je houdt toch ook gewoon ergens bij of er iemand is ingelogd met een BIT bijvoorbeeld, als iemand dan uitlogt via de logout knop zet je dat BIT weer op 0 en mag er weer iemand anders inloggen, bij de Session_OnEnd zet je ook dat BIT op 0.
En als de Session_OnEnd niet is opgetreden dan geldt dat bij DateDiff(UpdateDate, Now) > Session.TimeOut een nieuwe gebruiker toch mag inloggen.

Imho zijn er 2 methodes om uit te loggen: Via de uitlogknop en botweg je scherm afsluiten, welke oorzaak dat dan ook heeft.
Eerste methode, gewoon uitloggen, verwacht ik geen probleem mee; niemand eik.

Als ik echter gewoon botweg m'n browser wegklik, vraag ik me af of de session_onend gefired wordt.

[DeverauX]

Als ik echter gewoon botweg m'n browser wegklik, vraag ik me af of de session_onend gefired wordt.

Nee dit is inderdaad niet het geval. De session_onend state treedt alleen op wanneer binnenin het gespecificeerde tijdsinterval géén request wordt gedaan, in dit geval dus na een periode van 20 minuten

[Verwijderd]

DeverauX schreef op 07 June 2003 @ 11:04:
[...]

Nee dit is inderdaad niet het geval. De session_onend state treedt alleen op wanneer binnenin het gespecificeerde tijdsinterval géén request wordt gedaan, in dit geval dus na een periode van 20 minuten

Is er ook een manier waarmee dit wel ge-automatiseerd kan worden als een user zijn browserschermpje sluit?

[gorgi_19]

Verwijderd schreef op 11 June 2003 @ 15:09:
Is er ook een manier waarmee dit wel ge-automatiseerd kan worden als een user zijn browserschermpje sluit?

Betrouwbaar? nope.

[Verwijderd]

gorgi_19 schreef op 11 June 2003 @ 15:12:
[...]

Betrouwbaar? nope.

Ennuh, wat als we het op een onbetrouwbare manier gaan doen dan?

[gorgi_19]

Verwijderd schreef op 11 juni 2003 @ 15:18:
[...]


Ennuh, wat als we het op een onbetrouwbare manier gaan doen dan?

Bij een body Onload Method ('t is clientside ) een popupje laten openen, welke je uit laat loggen.

[Verwijderd]

mmmmm...

dat is misschien wel een leuk idee-tje ja.

[Verwijderd]

Maarja, je blijft natuurlijk zitten met mensen die een pop up killer zitten?

[gorgi_19]

Verwijderd schreef op 11 juni 2003 @ 15:22:
Maarja, je blijft natuurlijk zitten met mensen die een pop up killer zitten?

gorgi_19 schreef op 11 juni 2003 @ 15:12:
[...]

Betrouwbaar? nope.

[Verwijderd]

Ik zien het... Ik zien het...

Maar iig thanks sofar... Ik ben een stukje verder, hoop nog wat verder te komen, maar dit is iig een mooi iets al!

[robjanssen]

Verwijderd schreef op 11 June 2003 @ 15:22:
Maarja, je blijft natuurlijk zitten met mensen die een pop up killer zitten?

Hiervoor had ik deze oplossing:
En als de Session_OnEnd niet is opgetreden dan geldt dat bij DateDiff(UpdateDate, Now) > Session.TimeOut een nieuwe gebruiker toch mag inloggen.

[Verwijderd]

robjanssen schreef op 11 juni 2003 @ 19:20:
[...]


Hiervoor had ik deze oplossing:
En als de Session_OnEnd niet is opgetreden dan geldt dat bij DateDiff(UpdateDate, Now) > Session.TimeOut een nieuwe gebruiker toch mag inloggen.

Thanks, misschien dat het allemaal te implementeren valt.