[ASP.NET] meerdere logins met 1 useraccount

[djlinsen]

Ik wil op een asp.net website voorkomen dat mensen met het zelfde username-password meerdere keren tegelijk in kunnen loggen.

De eerste oplossing die in mij opkwam is om in de database een flag te zetten wanneer de user inlogt en deze weer op 0 te zetten als de user de site verlaat. Hier loop ik tegen de voornaamste problemen op: Zolang de user braaf de logout knop gebruikt, gaat dit prima. Ook als de sessie verloopt wordt netjes Session_End aangeroepen en in die functie wordt de user weer vrijgegeven. Echter wordt daarmee de gebruiker gestraft en zal op de session time out moeten wachten voor er opnieuw ingelogd kan worden als hij bijvoorbeeld de browser heeft afgesloten zonder op uitlog knop te drukken.

Op internet kwam ik deze oplossing tegen: http://www.eggheadcafe.com/articles/20030418.asp

Maar dit is ook niet alles, ook hier moet de gebruiker wachten tot de sessie afgelopen is.

Iemand een goed idee om dit probleem op te lossen?

[Niemand_Anders]

Als je gewoon de login in een encrypted token cookie wegschrijft kun je werken met persistent logins. Dat bied je de mogelijkheid om in je database bij te houden dat een gebruiker is ingelogd. Zolang de database aangeeft dat de gebruiker is ingelogd kun je dus niet inloggen. Bij elk request kun je vervolgens in de database controleren of het token nog steeds aan een account is gekoppeld. Logt de gebruiker via een andere browser/locatie/whatever opnieuw in, dat zal aan dat account een nieuw token worden toegekend waardoor de cookie met het oude token ongeldig wordt.

Op die manier kun je vrij eenvoudig een single login enforcen. Om de token een extra security laag te geven is het wel verstandig een checksum hash naar een cookie weg te schrijven. Gebruik hiervoor een hmac hash omdat je dan het userid - gevolg door een vaste key welke alleen bekend is bij de website (bijv. userid: 18394, key voor hmac: K18394MyWebsite.nl) - kunt gebruiken als extra beveiliging. Daarmee voorkom je dat de gebruiker het userid of inlog token kan veranderen om zo de gegevens van andere gebruikers te kunnen zien.

[djlinsen]

Niemand_Anders schreef op dinsdag 08 januari 2008 @ 13:16:
Als je gewoon de login in een encrypted token cookie wegschrijft kun je werken met persistent logins. Dat bied je de mogelijkheid om in je database bij te houden dat een gebruiker is ingelogd. Zolang de database aangeeft dat de gebruiker is ingelogd kun je dus niet inloggen. Bij elk request kun je vervolgens in de database controleren of het token nog steeds aan een account is gekoppeld. Logt de gebruiker via een andere browser/locatie/whatever opnieuw in, dat zal aan dat account een nieuw token worden toegekend waardoor de cookie met het oude token ongeldig wordt.

Op die manier kun je vrij eenvoudig een single login enforcen. Om de token een extra security laag te geven is het wel verstandig een checksum hash naar een cookie weg te schrijven. Gebruik hiervoor een hmac hash omdat je dan het userid - gevolg door een vaste key welke alleen bekend is bij de website (bijv. userid: 18394, key voor hmac: K18394MyWebsite.nl) - kunt gebruiken als extra beveiliging. Daarmee voorkom je dat de gebruiker het userid of inlog token kan veranderen om zo de gegevens van andere gebruikers te kunnen zien.

Zoals je zelf al zegt, zolang de database zegt dat er niet ingelogd kan worden komt er geen user in met het zelfde account. Daar ligt ook precies het probleem. Hoe zorg ik er voor dat de database altijd up to date is. Met behulp van de logout knop gaat dat prima natuurlijk, maar als een user gewoon de browser afsluit, zal de user ingelogd blijven tot dat de session verloopt of iets dergelijks.

[sky-]

Multisessions gebruiken.

Een standaard sessie tijd instellen, bijvoorbeeld 60 minuten. Logt de gebruiker niet uit (zonder logout knop oid) dan moet ie de resterende minuten wachten die nog in de sessie actief zijn.

[Not Pingu]

djlinsen schreef op dinsdag 08 januari 2008 @ 13:41:
Zoals je zelf al zegt, zolang de database zegt dat er niet ingelogd kan worden komt er geen user in met het zelfde account. Daar ligt ook precies het probleem. Hoe zorg ik er voor dat de database altijd up to date is. Met behulp van de logout knop gaat dat prima natuurlijk, maar als een user gewoon de browser afsluit, zal de user ingelogd blijven tot dat de session verloopt of iets dergelijks.

Als het sluiten van de browser e.d. het probleem vormt, genereer dan gewoon een session token op basis van het IP adres van de gebruiker oid, of zet een persistent cookie met een gegenereerde machine ID (dus niet met userspecifieke gegevens).

Dan zit je wel met de vraag: wat doe ik als dezelfde user tegelijkertijd op 2 machines inlogt? Dan kun je gewoon zeggen: bij de tweede login wordt de eerste sessie automatisch afgesloten, of juist dat de gebruiker idd niet een 2e keer kan inloggen als ie ergens anders een actieve sessie heeft.

[ Voor 16% gewijzigd door Not Pingu op 08-01-2008 13:55 ]

[djlinsen]

sky- schreef op dinsdag 08 januari 2008 @ 13:44:
Multisessions gebruiken.

Een standaard sessie tijd instellen, bijvoorbeeld 60 minuten. Logt de gebruiker niet uit (zonder logout knop oid) dan moet ie de resterende minuten wachten die nog in de sessie actief zijn.

Dit gebruik ik nu, alleen is dit totaal niet gebruiksvriendelijk, de gebruiker wordt bij het afsluiten van de browser in dit geval voor 60 minuten op het strafbankje gezet en mag niet meer inloggen.

@Not Pingu: Hoe kan ik controlleren of er al een actieve sessie ingebruik is?
Wordt een actieve sessie ook direct verwijderd wanneer de browser afgesloten wordt?

[ Voor 13% gewijzigd door djlinsen op 08-01-2008 14:08 ]

[Not Pingu]

djlinsen schreef op dinsdag 08 januari 2008 @ 14:05:
@Not Pingu: Hoe kan ik controlleren of er al een actieve sessie ingebruik is?
Wordt een actieve sessie ook direct verwijderd wanneer de browser afgesloten wordt?

Dat doe je serverside. De cookie gebruik je alleen om een user en/of machine te identificeren, niet als implicatie dat deze user ingelogd is. In je applicatie kun je bijhouden of de user een actieve sessie heeft (combinatie van user en machine) en eventueel de lopende sessie vervangen door een nieuwe als diezelfde user op een andere machine inlogt.

[Niemand_Anders]

Een gebruiker kan altijd inloggen. Alleen als de gebruiker inlogt, dan wordt de vorige inlog token ongeldig.

Als je aan een cookie geen expire tijd meegeeft, dan blijft deze aanwezig tot de browser wordt gesloten. Geef je een cookie bijv. een expire tijd van een week, dan blijft de gebruiker op basis van userid/inlog token een week ingelogd of totdat het inlog token in de user tabel wordt overschreven door een nieuw token. Dat verloopt uiteraard de cookie direct (het heeft immers geen zin deze langer te bewaren).

Door het token aan het profiel zelf te koppelen (via een veld in tblProfile) is er voor dat profiel altijd maar 1 login mogelijk en daarmee voorkom je dat een bezoeker via meerdere browsers/computers meerdere malen inlogt.

[Cartman!]

Gewoon een losse session handler schrijven (ik heb het gebouwd voor mn eigen framework (PHP) en MyReact/T.net maakt gebruik van hetzelfde idee). Los een session tabel maken met een random code (je session code, of ReactId zoals het hier heet). Die code sla je op in een cookie op de client en bij elke pagina opvraag check je of er een cookie is met een geldige session code. Als je die hebt ben je inloged als de user die hoort bij die session code. Zo kun je meerdere logins tegelijk hebben en elke session locken op een tijd of ip adres mocht je dat willen.

[Not Pingu]

Cartman! schreef op dinsdag 08 januari 2008 @ 16:18:
Gewoon een losse session handler schrijven (ik heb het gebouwd voor mn eigen framework (PHP) en MyReact/T.net maakt gebruik van hetzelfde idee). Los een session tabel maken met een random code (je session code, of ReactId zoals het hier heet).

Opslaan in de DB lijkt me overbodig aangezien deze informatie alleen op korte termijn nuttig is. Dus tenzij je applicatieplatform geen globale in-memory variabelen toe laat, zou ik dit lekker in-memory opslaan.

[Cartman!]

Hoe wil je dan bijhouden of iemand ingelogd is, of iemand meerdere keren ingelogd etc. ?

[Not Pingu]

Cartman! schreef op dinsdag 08 januari 2008 @ 17:08:
Hoe wil je dan bijhouden of iemand ingelogd is, of iemand meerdere keren ingelogd etc. ?

Dat zeg ik toch, serverside in-memory. Heeft als bijkomend voordeel dat een backup/restore van je database niet met je lopende sessies kan storen.

[Cartman!]

Misschien dat ik je niet goed begrijp dan... maar wat als je wilt dat iemand een jaar ingelogd kan blijven? Dat een jaar in het geheugen laten zitten? Dat lijkt me niet wenselijk.

[Not Pingu]

Cartman! schreef op dinsdag 08 januari 2008 @ 21:18:
Misschien dat ik je niet goed begrijp dan... maar wat als je wilt dat iemand een jaar ingelogd kan blijven? Dat een jaar in het geheugen laten zitten? Dat lijkt me niet wenselijk.

Zoals op GoT bijv? Dat kan met een persistent cookie zodat de user automatisch ingelogd wordt als hij/zij de site bezoekt. Je hoeft in principe maar 1 actieve sessie per user bij te houden (als we het dus hebben over het 1 sessie per user verhaal) dus veel geheugen zal dat niet innemen.

[Toolskyn]

Not Pingu schreef op dinsdag 08 januari 2008 @ 21:23:
[...]


Zoals op GoT bijv? Dat kan met een persistent cookie zodat de user automatisch ingelogd wordt als hij/zij de site bezoekt. Je hoeft in principe maar 1 actieve sessie per user bij te houden (als we het dus hebben over het 1 sessie per user verhaal) dus veel geheugen zal dat niet innemen.

Als je je sessies alleen maar in het geheugen opslaat en om wat voor reden dan ook je server software uitvalt ben je dus gelijk al je sessies kwijt, daar doen cookies ook niets aan.

[Cartman!]

Precies, daarom lijkt dat me absoluut geen optie. En het ging toch juist om meerdere logins per user? Waarom heb je het dan over 1 actieve sessie per user... dat is toch wat we niet willen?

[Not Pingu]

Cartman! schreef op woensdag 09 januari 2008 @ 08:57:
Precies, daarom lijkt dat me absoluut geen optie. En het ging toch juist om meerdere logins per user? Waarom heb je het dan over 1 actieve sessie per user... dat is toch wat we niet willen?

1e zin uit de ts:

Ik wil op een asp.net website voorkomen dat mensen met het zelfde username-password meerdere keren tegelijk in kunnen loggen.

En is het kwijtraken van sessie-informatie bij een applicatie-restart echt zo erg? Dan moeten gebruikers alleen even opnieuw inloggen. Unsaved informatie zijn ze sowieso kwijt. Het lijkt me erger dat na een restore van de database ineens een aantal sessies weer actief zijn die al afgesloten waren, waardoor bijv. iemand op een public PC ineens ingelogd is op het account van een persoon die daar ooit een keer heeft geauthenticeerd met je website.

Informatie over lopende sessies is enkel tijdelijk bruikbaar, het heeft dus geen zin deze te persisten in je DB.

[djlinsen]

Not Pingu schreef op woensdag 09 januari 2008 @ 09:07:
[...]
En is het kwijtraken van sessie-informatie bij een applicatie-restart echt zo erg? Dan moeten gebruikers alleen even opnieuw inloggen. Unsaved informatie zijn ze sowieso kwijt. Het lijkt me erger dat na een restore van de database ineens een aantal sessies weer actief zijn die al afgesloten waren, waardoor bijv. iemand op een public PC ineens ingelogd is op het account van een persoon die daar ooit een keer heeft geauthenticeerd met je website.

Informatie over lopende sessies is enkel tijdelijk bruikbaar, het heeft dus geen zin deze te persisten in je DB.

precies, liever dat een gebruiker een keer te vaak opnieuw moet inloggen dan dat er misbruik mogelijk is of dat er niet meer in te loggen valt.
Ik heb momenteel nog even geen tijd om de sugesties van jullie uit te werken, maar ik denk dat ik door heb welk mechanisme ik hiervoor moet gebruiken. De uiteindelijke oplossing zal ik hier nog posten en anders volgen er nog enkele vragen in dit topic, bedankt allemaal in iedergeval!