[alg/.net]Membership

[Woy]

Ik ben op het moment aan het kijken hoe we hier een nieuw Membership en Personalization framework op kunnen zetten voor onze web-applicaties. We hebben op het moment een aantal clasic asp sites, een aantal asp.net 1.1/1.0 sites en zijn op het moment bezig om over te stappen op asp.net 2.0.

De huidige situatie is dat de membership ( autenticatie ) gedaan wordt door SiteServer. Dit is een erg oud pakket van microsoft wat ook niet meer ondersteund wordt ( En op Windows Server 2003 niet eens draait ) en wat ook niet echt goed samenwerkt met .net. Vandaar dat we graag iets nieuws willen ontwikkelen/gaan gebruiken.

Nou zit er in asp.net 2.0 een uitgebreidt framework voor Membership/Role based authentication/Personalization dat zeker goed te gebruiken en uit te breiden is voor onze wensen. \

Het probleem is nou dat het eigenlijk de bedoeling is dat alle oude applicaties ook gebruik gaan maken van de nieuwe techniek ( Omdat het lastig is om 2 systemen te blijven onderhouden en omdat het de bedoeling is dat de servers langzaam aan omgezet worden naar Windows 2003 ).

Nou kan je natuurlijk in classic asp en .net 1.x geen gebruik maken van de nieuwe libraries. De .net 1.x applicaties kunnen waarschijnlijk nog wel redelijk eenvoudig geport worden maar voor classic asp is dat natuurlijk niet het geval.

Wat ik nou eigenlijk wil bereiken is dat ik in .NET 2.0 een framework schrijf en die gewoon in de asp applicaties kan gebruiken. Dus dat de Authentication standaard door het framework wordt gedaan. De asp applicaties maken gebruik van een COM+ component wat hier gemaakt is dus dit component zou ik dan willen vervangen voor een ander component met dezelfde interface die die functionaliteit doorpast aan het nieuwe framework.

Mijn vraag is nou echter hoe kan ik er voor zorgen dat de Authenticatie door mijn component gecontroleerd wordt. Ik kan natuurlijk wel een ISAPI dll schrijven die dat afhandeld maar eigenlijk wil ik wel gebruik blijven maken van de standaard functionaliteit die het .NET 2.0 framework biedt.

Verder zou ik graag willen weten hoe andere het probleem van Membership opgelost hebben. Het lijkt me namelijk niet dat iedereen elke techniek weer een apart systeem heeft.

[P_de_B]

Het eerste wat in me op komt: kun je niet een COM wrapper om de .Net functionaliteit maken en dit com object aanspreken vanuit classic asp?

[Woy]

P_de_B schreef op vrijdag 24 februari 2006 @ 10:31:
Het eerste wat in me op komt: kun je niet een COM wrapper om de .Net functionaliteit maken en dit com object aanspreken vanuit classic asp?

Ja dat moet wel lukken en dat was inderdaad ook een van mijn ideen. Maar dan wordt de Authenticatie check natuurlijk nog niet uitgevoerd aangezien dat eigenlijk al gebeurt voordat je page geladen wordt.

[Not Pingu]

Een van de beste manieren om interoperabiliteit tussen twee systemen te verzorgen, is webservices. Als je een Membership library opzet en de nodige functies (authenticaten, status opvragen, uitloggen, etc.) dmv. webservices toegankelijk maakt, kun je die webservices vanuit je klassieke ASP applicatie aanspreken.

Of je bouwt ipv. een webservice een paar kleine paginaatjes die bijv. met querystring input kunnen werken, dat is wat makkelijker aan te spreken vanuit klassiek ASP.

[P_de_B]

rwb schreef op vrijdag 24 februari 2006 @ 10:39:
[...]

Ja dat moet wel lukken en dat was inderdaad ook een van mijn ideen. Maar dan wordt de Authenticatie check natuurlijk nog niet uitgevoerd aangezien dat eigenlijk al gebeurt voordat je page geladen wordt.

Ah, je wilt de aanroep naar het COM object niet doen in de asp pagina zelf. Zou het isapi filter niet hetzelfde COM object kunnen aanspreken?

[Woy]

P_de_B schreef op vrijdag 24 februari 2006 @ 11:24:
[...]


Ah, je wilt de aanroep naar het COM object niet doen in de asp pagina zelf. Zou het isapi filter niet hetzelfde COM object kunnen aanspreken?

Nou ik wil het COM object wel aanspreken vanuit de asp pagina zelf, het COM object zal echter op een of andere manier toch moeten weten welke gebruiker de huidige gebruiker is. Ook wil ik niet dat ik bij elke pagina bovenaan moet zetten

code:

AutenticateUser()

of iets dergelijks. Wat ik eigenlijk wil is dat voordat de pagina geladen is dat de user al Authenticated en Authorized is. Daarna wil ik in de pagina gewoon het COM object aanmaken om properies op te kunnen vragen.

Een COM object maken en die laten communiceren met het nieuwe framework is op zich het probleem niet. Maar hoe zorg ik er voor dat het COM component weet welke user de pagina bezoekt zonder elke keer tegen het component te vertellen welke user er in is gelogd.

Wat ik dus eigenlijk wil is dat mijn asp applicatie hetzelfde werkt als de asp.net applicatie dus als volgt

User vraagt pagina op -> framework controleert of Auth Ticket aanwezig is -> zo niet stuurt naar globale login pagina -> user logt in en krijgt een Auth Ticket -> User wordt doorgestuurd naar de pagina waar hij vandaan kwam -> framework controleert Auth Ticket -> Framework ziet dat alles goed is en laat dan de pagina zijn werk doen.

In een ASP.NET applicatie maak ik dan gewoon direct gebruik van de API die je tot je beschikking hebt om Profiles te gebruiken.

Voor ASP wil ik dan een COM wrapper maken die volgens de volgende manier gebruikt kan worden

ASP:

dim profileManager = CreateObject( "MyProfileWrapper" )
profileManager.GetProperty( "BirthDay" )

Ik denk dat ik voor de authenticatie uiteindelijk wel terecht kom bij een ISAPI filter omdat dat volgens mij de enige plek is waar je kan authenticaten zonder dat de pagina executie al daadwerkelijk gestart is. Maar ik heb geen idee hoe ik dan kan zorgen dat mijn COM component ook bij de gegevens kan waardoor hij kan zien wie er ingelogd is.

[Woy]

Even een kickje.

Ik heb ondertussen ondekt dat je met ASP.NET 2.0 en IIS 6 gebruik kunt maken van de security van het .NET framework door in IIS de aspnet_isapi in te stellen als wildcard handler. Dan kan je daarbij zelf een subclass maken van DefaultHttpHandler en daarin kan je een aantal headers aan het request toevoegen. Zo wordt er voor gezorgd dat alle resources eerst door asp.net geauthenticate worden en je kan daarover ook gegevens doorgeven aan clasic asp door middel van headers.

Het enige puntje waar ik nu nog mee zit is dat ik eigenlijk vanuit een COM component gegevens wil hebben uit het asp request. Bij de oude manier van werken wordt er namenlijk een COM component aangemaakt en op een of andere manier weet die welke user er op dat moment is ingelogd. Het lijkt me dat hij dat kan zien aan de hand van de headers. Op zich zou ik natuurlijk ook een initializatie methode kunnen maken waar ik aan mee geef voor welke user het is, maar aangezien de SiteServer dll blijkbaar ook bij de gegevens van het request kan lijkt het me dat ik dat zelf ook zo zou moeten kunnen doen. Dus als iemand daar nog ideen over heeft zou dat mooi zijn.

[Woy]

kick.

Niemand die een idee heeft hoe ik in een COM component gegevens uit kan lezen over de ingelogde gebruiker op de website? Eigenlijk zou ik dus gewoon bij de Request data willen kunnen. Kan dat dan echt alleen door de gegevens door te geven na het creeren van het object?