Concurrent named users voorkomen (C# webbased)

[SeatRider]

Wij hebben een webbased applicatie (content management systeem) dat werkt met named users. Klanten kopen licenties op dat systeem per user. Je raadt het al, iedereen gebruikt gewoon de admin user en vindt 1 licentie wel genoeg.

Natuurlijk is dit afgedicht in de licentievoorwaarden, maar zolang het werkt malen ze daar niet naar, en wij hebben het nakijken. We willen dus voorkomen dat users gelijktijdig kunnen inloggen. Helaas is het een Clickonce applicatie die verbindt met webservices, die dus stateless is.

We kunnen dus wel sessies bijhouden, maar het kan gebeuren dat een gebruiker gewoon de applicatie op 1 werkstation hard afsluit (waardoor de server de sessie nog even openhoudt). Klakkeloos een user toegang weigeren omdat de sessie nog bestaat is dus niet zo netjes - zeker niet als de user daarvoor net uit de applicatie is gegooid na een crash/programmeerfout van onszelf .

Andere optie zou zijn indien een tweede sessie wordt gemaakt, gewoon de eerste verwijderen. Dat levert dan weer schoonheidsproblemen, de client moet dan ineens rekening houden met het feit dat serverside ineens de sessie wordt gekilled.

Kortom, we willen met zachte hand klanten opvoeden dat ze voor elke gebruiker moeten betalen, zonder dat daarmee "valide" gebruik lastig wordt gemaakt.

Dan hebben we ook nogklanten die zeggen, ja nee, we hebben maar 1 licentie nodig, want er zal toch nooit twee gebruikers gelijktijdig van het systeem gebruikmaken. Zouden we dan echt naar seat-licenses moeten gaan? Dat lijkt me nog veel irritanter bij te houden....

Iemand suggesties?

[Haan]

Je zou bij aanschaf van de applicatie door de klant, al afspraken moeten maken over het aantal users dat van je applicatie gebruik gaat maken. Een klant die maar 1 licentie wil, is bij voorbaat al verdacht waarschijnlijk. Het argument van klanten die zeggen dat er toch altijd maar 1 gebruiker actief zal zijn veeg je direct van tafel met je licentievoorwaarden waarin staat dat per gebruiker betaald moet worden.

Technisch is dit volgens mij erg lastig af te dichten, je kan heel moeilijk iets tegen account sharing doen als je inderdaad niet op een zelfde moment actief met je systeem werken.

Als gebruiker heb ik zelf ervaring met Dynamics CRM van Microsoft, waar je per gebruiker een Active Directory account moet koppelen en een licentie moet hebben. Maar ook daar wordt ten eerste al niet het aantal licenties afgedwongen (je kan dus bijv. 100 users aanmaken en maar 10 licenties hebben), en ten tweede is het ook perfect mogelijk om een account gelijktijdig door meerdere personen te laten gebruiken.

[ Voor 25% gewijzigd door Haan op 20-03-2010 11:04 ]

[Onbekend]

Ik neem aan dat er ook mensen zijn die meerdere sessies op 1 computer tegelijkertijd open hebben staan. Hiervoor willen ze natuurlijk geen extra licenties afnemen.


Stel dat je nu maximaal 4 actieve sessies per user accepteert. Als er 10 minuten niets met een sessie wordt gedaan verwijder je hem, zodat andere mensen hem kunnen gebruiken. (Met een logout-knop kunnen ze een sessie natuurlijk altijd beëindigen)
Een 5e sessie accepteer je gewoon niet, totdat er een andere sessie vrijkomt.

[Rob]

Misschien een idee om bij een 2e sessie van een gebruiker een opvallende rode balk bovenin te plaatsen die de gebruiker vertelt dat hij/zij tweemaal ingelogged is en dat niet mag.

Vervelend voor de gebruiker, maar het beperkt niet.
Misschien hebben sommige mensen al niet door dat ze dingen doen die niet mogen.

[eek]

Begrijp ik het goed dat de applicatie runt op een workstation? Zou je niet iets kunnen doen met het lokale ip-adres van de gebruiker?

[Korben]

Wat je ook zou kunnen doen, wel minder gebruikersvriendelijk, maar wel onoverkomelijk, is wanneer er iemand inlogt en er is nog een openstaande sessie, die dan beëindigen. Mensen die hun applicatie hard beëindigen hebben daar geen last van, maar mensen die 2 sessies tegelijkertijd willen doen wel.

[kluyze]

Hoe runt de applicatie eigenlijk? Is het een applicatie+database bij de klant of staat alleen de database bij jullie? Of draait de gehele applicatie+database bij jullie? Is het een html pagina of gebruiken jullie iets als silverlight?

Je zou eigenlijk client side iets moeten kunnen doen. Ik denk iets aan een key die bij de creatie van een sessie gegenereerd wordt en die ook in een cookie op de client opgeslagen wordt. De problemen die dan boven komen is dat de klant dat soort dingen kan uitzetten (javascript/cookies) en je wilt niet dat die verplicht aan staan omdat dan je dan misschien klanten misloopt die systemen gebruiken waar het gewoon niet mogelijk is.

Wat ook misschien kan is een ander systeem dat je een admin account hebt maar dat die niet gebruikt mag worden om het systeem te gebruiken maar bij een systeemcrash of iets dergelijks, dat die mag inloggen om de sessies te resetten. En dat er dus altijd een user account naast de admin aangeschaft wordt.

Ik denk niet dat er een perfecte oplossing bestaat en dat je dus ergens zelf keuzes gaat moeten afwegen.

[H!GHGuY]

Is het gebruik van FlexLM een optie?

[SeatRider]

De applicatie is een smart client die via Clickonce installeert. De database (server) kan zowel bij ons als bij een klant gehost staan. 2x inloggen per gebruiker vind ik wel een goed idee eigenlijk, zeker als je bij de 2e keer inloggen een waarschuwing krijgt .

Andere suggesties?

[Onbekend]

Ik ben totaal niet bekend met die software. Hoeveel controle heb je over de client? En tot hoever kan je de gegevens uitlezen? Anders kan je d.m.v. bijvoorbeeld het MAC-adres van de computer dit als een unieke gebruiker kunnen aanmerken, en zou je de licentie op basis van het aantal computers moeten liggen.

[analog_]

Lijkt me om eerlijk te zijn gewoon intressanter om de Admin het onmogelijk te maken om een dagelijkse productie taak te doen, administratie functies en daar houdt het een beetje bij op. Dan forceer je ze zowieso tot de koop van minimum één licentie en zullen ze er wat bewuster mee omgaan. Je zou overigens prima zo'n een user mag maar ingelogd zijn systeempje kunnen maken zolang de admin dan maar één sessie handmatig kan verwijderen indien nodig of je laat er een timer over lopen ofzo.

[Vinnienerd]

Wat als je nou de licentielogica door de client met een aparte server af laat handelen? Een soort sessie-systeem?

[xtra]

Misschien kun je bij een nieuwe sessie vragen of de oude gesloten kan worden. Na een crash is het antwoord natuurlijk ja. Als er nog een ander zit te werken mogen ze zelf kiezen.

Ik weet niet of je in een Click once applicatie het SID van de PC mag uitlezen. Als dan dezelfde gebruiker inlogt met een ander SID weet je dat de licentie wordt overtreden. (Tenzij er toch nog een oude sessie actief is van een gecrashde PC oid.)

Met een keep alive systeempje kun je de sessies in ieder geval lekker kort houden.

[LauPro]

Is het niet gewoon handiger om naar een ander licentiemodel te kijken? Misschien de prijs iets omlaag doen per gebruiker gewoon standaard meer accounts aan te maken. Of een tarief naar het aantal medewerkers van het bedrijf. Etc.

[downtime]

LauPro schreef op zaterdag 20 maart 2010 @ 18:13:
Is het niet gewoon handiger om naar een ander licentiemodel te kijken? Misschien de prijs iets omlaag doen per gebruiken gewoon standaard meer accounts aan te maken. Of een tarief naar het aantal medewerkers van het bedrijf. Etc.

Een tarief naar het aantal medewerkers van het bedrijf is vrij kansloos natuurlijk. Stel een multinational met 50.000 werknemers koopt 10 licenties van je pakket voor een kleine afdeling. Ga je dan een tarief hanteren wat op 50.000 werknemers gebaseerd is? Ik denk dat je dan een klant kwijt bent.

[Compuhair]

LauPro schreef op zaterdag 20 maart 2010 @ 18:13:
Is het niet gewoon handiger om naar een ander licentiemodel te kijken?

Ik vind dit een goede suggestie.

Kijk bijvoorbeeld naar het aantal items dat geregistreerd wordt. Heb je een offertesysteem dan betaal je per offerte. Heb je een klachtenregistratie systeem, dan betaal je voor het aantal klachten dat je registreert.

Je zou dit vooraf kunnen regelen:
Wil je 1 t/m 999 klachten registreren, dan betaal je X
wil je 1000 t/m 10.000 klachten registreren, dan betaal je 2X
etc.

Of achteraf:
Je hebt afgelopen maand 549 klachten geregistreerd, per klacht is het 1 euro, dus betaal je 549,-.
Je hebt 1549 klachten geregistreerd, per klacht kost het 90 cent (kwantumkorting, dus betaal je xx.

Klein voorbeeldje, en dit soort afrekenmechanismes zijn natuurlijk voor elke situatie te verzinnen. Zeker nu we steeds vaker met cloud computing te maken hebben en minder vaak met bij de klant geinstalleerde systemen zullen we steeds meer dan andere manieren van afrekenen moeten kijken.

[SeatRider]

Ik vind deze discussie inderdaad interessant worden. Maar wat nou als het gaat om dingen als websites. Of presentaties. Dingen die niet per definitie meer worden. Hooguit verbeterd...

[downtime]

SeatRider schreef op zaterdag 20 maart 2010 @ 20:52:
Ik vind deze discussie inderdaad interessant worden. Maar wat nou als het gaat om dingen als websites. Of presentaties. Dingen die niet per definitie meer worden. Hooguit verbeterd...

Als aanpassing van het licentiemodel een serieuze optie is dan kun je bij een CMS ook denken aan een tarief per beheerde site (of pagina) voor elke dag/week/maand dat ie actief is. Eerlijk gezegd klinkt dat ook nuttiger dan een licentie per user omdat dat makkelijk te beinvloeden is door zo weinig mogelijk mensen sitebeheerder binnen een bedrijf te maken.

Vraag is natuurlijk hoe je zo'n licentiewijziging aan je bestaande klanten verkoopt. Of accepteer je dat bestaande klanten volgens een ander licentiemodel betalen dan toekomstige klanten?

[SeatRider]

downtime schreef op zaterdag 20 maart 2010 @ 21:05:
[...]
Vraag is natuurlijk hoe je zo'n licentiewijziging aan je bestaande klanten verkoopt. Of accepteer je dat bestaande klanten volgens een ander licentiemodel betalen dan toekomstige klanten?

Dat laatste is zeker geen probleem wat mij betreft .

[LoBbY_1]

Of op nacalculatie het aantal duplicate sessies belasten Als je alles registreert is dit een fluitje van een cent.

[Hydra]

Ik snap eigenlijk niet waarom je niet gewoon voor het uitloggen van de oude sessie gaat. Er is m.i. geen enkele reden een oude sessie te laten bestaan als met dezelfde username opnieuw ingelogged wordt. MMO's werken bijvoorbeeld ook zo, om te voorkomen dat je met twee personen een account deelt.

[jip_86]

Hydra schreef op maandag 22 maart 2010 @ 11:41:
Ik snap eigenlijk niet waarom je niet gewoon voor het uitloggen van de oude sessie gaat. Er is m.i. geen enkele reden een oude sessie te laten bestaan als met dezelfde username opnieuw ingelogged wordt. MMO's werken bijvoorbeeld ook zo, om te voorkomen dat je met twee personen een account deelt.

Ben ik het ook mee eens. Je laat je klanten betalen voor een account, dan is er ook geen enkele reden om die twee keer in te laten loggen.