State Persistance zonder Cookies

[Davio]

Beste Tweakers,

Voor een project waar ik binnenkort mee ga beginnen, hebben we het volgende probleem.

Binnen een interne omgeving zullen gebruikers onze website benaderen en eventueel één keer in moeten loggen. Deze login moet een timeout krijgen van 4 uur na de laatste activiteit.

Onze website zal benaderd worden via een OCX-control waar automatisch onze URL in geplakt wordt. Het kan zo zijn dat deze OCX op een gegeven moment afgesloten wordt, maar wij willen de login dan wel bewaren, zodat gebruikers niet elke keer in hoeven te loggen. Wij beheren het programma dat de OCX aanroept ook niet en dus kunnen we er niet vanuit gaan dat deze maar één keer geïnitialiseerd wordt.

Een ander probleem is dat we geen Cookies op kunnen slaan, Sessies kunnen we wel gebruiken.

De vraag is dus: Hoe kunnen we een login bewaren over verschillende sessies heen zonder Cookies? Is dit überhaupt mogelijk? Omdat de systemen redelijk uniform zullen zijn, kunnen we er (ook vanwege veiligheidsredenen) niet op aan dat er unieke systemen zijn (browser-instellingen detecteren) die unieke gebruikers identificeren.

Ik heb al op internet gezocht, maar kan de goede keywords niet aan elkaar knopen om een bevredigend antwoord te krijgen. Ik twijfel ook of die bestaat.

Is het dus mogelijk en zo ja, hoe, om logins over verschillende sessies te bewaren zonder de makkelijke tools?


Edit: Het enige wat ik gevonden heb, gaat dus over Browser Fingerprinting: http://news.cnet.com/8301-1009_3-20005185-83.html
Dit lijkt me alleen interessant als aanvulling op gebruikersvalidatie of no-login/no-cookie tracking zoals advertisers dat zouden willen.

[Voor 8% gewijzigd door Davio op 05-12-2011 11:55]

[djluc]

Hoe weet de server dan welke sessie er is? Een sessie staat toch standaard in een cookie? Of heb je een alternatief daarvoor in gebruik zoals sessies die in de url geplaatst worden?

[Davio]

djluc schreef op maandag 05 december 2011 @ 11:55:
Hoe weet de server dan welke sessie er is? Een sessie staat toch standaard in een cookie? Of heb je een alternatief daarvoor in gebruik zoals sessies die in de url geplaatst worden?

Ja, op het moment dat een gebruiker eenmaal een 1e x is ingelogd, kunnen we de pagina's wel dynamisch een Sessie-ID mee laten sturen. Over de veiligheid hiervan valt ook te discussiëren, maar dit valt op zich wel mee. Veelal zal dezelfde gebruiker een tijdlang dezelfde computer bedienen, en als een gebruiker niet uitlogt terwijl hij een tijd fysiek afwezig is, dan is dit niet ons probleem.

Omdat het voor intern gebruik is, kunnen we er wel vanuit gaan dat de personen die de systemen bedienen in ieder geval bevoegd zijn en al een keer geverifieerd zijn (via pasjes oid).

We willen de gebruiker echter niet constant lastigvallen met een loginscherm als dit niet hoeft. Ons grootste euvel is daarom de OCX die de sessie-informatie niet wil bewaren.

[Mastermind]

Je zou het de laatste logintijd op userniveau bij kunnen houden in de database. Is de huidige tijd groter dan logintijd + 4 uur dan logt hij niet meer automatisch in, maar moet je opnieuw inloggen. Dan moet je de logintijd weer bijwerken naar de current time.

[Davio]

Dat is niet het probleem waar we mee zitten, Mastermind.

Het punt waar we op vast lopen, is hoe we aan de serverkant kunnen blijven valideren dat de gebruiker hetzelfde is als die van een uur geleden zonder dat we bijvoorbeeld cookies kunnen gebruiken.

Bij normale sites wordt jouw login tijdens een sessie vastgehouden door een session of cookies (ongeveer hetzelfde, maar net iets anders). Wij kunnen de login tijdens een sessie nog wel faken door een random sessie-id te genereren (GUID oid) en die overal mee te sturen en serverside te checken.

Het wordt echter lastiger om een gebruiker cross session te blijven valideren. Hier zouden normaliter cookies voor gebruikt worden.

Vergelijk het met browsen in Privacy Mode. Je kunt wel inloggen om van bepaalde functionaliteit gebruik te maken. Als je echter Privacy Mode afsluit, worden al jouw client-side bewaarde gegevens weggegooid. Wij zoeken een manier om die stiekem toch te behouden.

[--MeAngry--]

@Mastermind: Dat werkt heel leuk voor 1 gebruiker, maar met meer dan dat natuurlijk nooit.

Een IP-adres is niet uniek genoeg lijkt me? Anders kun je dat gebruiken natuurlijk.
De enige andere optie die ik dan kan bedenken is het MAC-adres gebruiken, maar ook dit is net als een IP te spoofen.

Je haalt dus eerst de ARP-table op van de webserver, en vervolgens ga je het IP-adres van de bezoeker matchen met het MAC-adres in de ARP-table. Dit kun je dan telkens opnieuw opzoeken.

[Voutloos]

De echte oplossing: deze specifieke cookies wel gewoon toestaan.

Houtje-touwtje oplossingen: Alternatieve persistent strorage trucs: localstorage, of unieke Last-Modified tijden of ETag headers met het session id erin. Lekker het wiel opnieuw uitvinden, met bovendien nog een mooie kans dat je lekker bezig kan blijven met je eigen sessie hacks bouwen en onderhouden.
[/sarcasm]

Echte oplossing part 2: Gebruikers domweg opnieuw laten inloggen, en klachten mogen dan rechtstreeks richting de persoon die over de no-cookie policy gaat.

[--MeAngry--]

Voutloos schreef op maandag 05 december 2011 @ 12:54:
[...]

Echte oplossing part 2: Gebruikers domweg opnieuw laten inloggen, en klachten mogen dan rechtstreeks richting de persoon die over de no-cookie policy gaat.

Uiteindelijk is dat inderdaad de enige plausibele optie die ook veilig is.

[Davio]

Aangezien onze site voornamelijk vanuit een beveiligde omgeving benaderd zal worden, is veiligheid een wat minder belangrijke kwestie. Volgens mij wordt het zo dat er zelfs een VPN komt naar onze server. Onze site zal dus niet zondermeer vanaf buitenaf te benaderen zijn.

Ik ben zelf heel erg voor de simpelheid van cookies of dat de OCX niet afgesloten wordt, zodat de sessie bewaard blijft. Dit zijn echter zaken waar we in dit project geen final say over hebben en daarom wil ik op voorhand al nadenken over onze worst case scenario's.

Het truukje met ARP zou daarom wel eens kunnen werken voor ons.

Bedankt voor jullie replies.

[Haan]

In ASP.NET kan je je site op 'cookieless' zetten, wat opzich prima werkt (afgezien van de lelijke URL's die je er van krijgt.
Ik ben nu zelf bezig met een vrij grote site die op cookieless gezet is, omdat de opdrachtgever een Citrix omgeving gebruikt waar cookies op willekeurige moment verwijderd worden, zodat je opeens je sessie kwijt bent en bent uitgelogd uit de site..

Groot nadeel van de cookieless mode is dat je gewoon de URL met sessie ID erin kan plakken bij iemand anders, en dan gewoon die sessie weer te pakken hebt.

[_Thanatos_]

Wat is die OCX voor iets? Zit daar een beetje behoorlijke layout engine in? If so, dan kun je toch localStorage en sessionStorage gebruiken?

Geef sowieso de maker van die OCX een schop, want cookies zijn gewoon een standaard web-iets en die hoor je gewoon te kunnen gebruiken voor dit soort dingen.

[Davio]

Nou, het is de schuld van de OCX-maker niet dat er geen Cookies gebruikt worden, dat is meer een company-wide policy.

Ik weet het fijne nog niet van de OCX, maar het zou bijvoorbeeld gewoon de WebBrowser control kunnen zijn die je binnen Visual Studio tot je beschikking hebt.

Ik vraag me dus af of die volledig ge-dispose'd wordt of dat er nog iets van bewaard blijft.

[_Thanatos_]

Tijd om te escaleren naar je manager. Cookies tegenhouden, zeker voor intern verkeer is gewoon te belachelijk voor woorden. What's next, ook maar de User-Agent en de Referer blokkeren?

"Luister, cookies zijn gewoon nodig. En wel omdat dit, en dit, en dit allemaal niet werkt en niet werkend te krijgen is."
Jouw manager mag het dan oplossen omdat je een company policy probleem bij hem hebt neergelegd. Als ie zegt "kan niet, je moet het gewoon fixen", heb je een stok achter de deur, want onmogelijk is onmogelijk. Je kunt niet toveren.

Je kunt er uren en uren tijd in steken, maar uiteindelijk kost dat verschrikkelijk veel geld. Als je dát ook nog als argument gebruikt, weet ik het ook niet meer. Dan werk je bij een advocaat, overheid, of een koppige ouwe knar.

Bedrijfspolitiek terzijde, WebBrowser is een IE zonder schil, als het ware, dus die "luistert" naar group policies. Een PortableApps.com installatie van Firefox ga je hiermee niet tegenhouden om cookies te accepteren, maar IE dus wel. Het lullige is zelfs dat je ook geen controle hebt over welke versie IE gebruikt wordt, omdat WebBrowser gewoon pakt wat je toevallig hebt. Handig! Maar misschien kun je iets met deze informatie