Thomas Bandt

Über mich | Kontakt | Archiv

Der eigene Custom MembershipProvider in 10 Minuten

Wozu das Ganze?

Nützlich ist es zum Beispiel immer dann, wenn man etwa bestehende Kunden- oder Login-Daten, etwa in Form einer SQL-Server-Tabelle vorliegen hat, und diese nun für einen Benutzerlogin nutzen will. Da bietet es sich ja förmlich an, oder anders ausgedrückt, es wäre sträflich die vorhandenen ASP.NET-Login-Controls nicht zu benutzen. Die sind nämlich so gut, dass sich damit viel handgestrickter Murks und vor allem Arbeit vermeiden lässt.

Das Problem ist jetzt nur, dass ASP.NET mit vielen eigenen Tabellen, Stored Procedures, Views usw. anrückt, die prinzipiell erstmal nicht mit den bestehenden Userdaten kommunizieren. Nun kann man sich die Frage stellen, ob man für einen simplen Login diesen ganzen Overhead benötigt.

Wenn man sich die Frage mit nein beantworten kann, dann bietet es sich in jedem Fall an, einen Custom MembershipProvider zu schreiben. Damit kann man dann auf die ASP.NET-Datenbank-Objekte verzichten und als Datenquelle direkt und ohne Umwege die eigene Kundentabelle benutzen. Das geht auf jeden Fall schneller, als ein Abgleich der Daten zw. ASP.NET-Tabellen und der eigenen, etwa per Trigger.

Wie geht es?

Relativ einfach. Als erstes legt man sich eine neue Klasse an, und leitet diese von MembershipProvider ab. Anschließend schiebt man seinen Mauszeiger geschmeidig über den Namen der Basisklasse und wartet kurz, bis sich folgendes Popup-Menü zeigt:


Ein Klick darauf implementiert alle Properties und Methoden, die überschrieben werden können. Das schaut auf den ersten Blick erstmal nach richtig viel Arbeit aus. Aber keine Bange, für einen einfachen Login benötigt man im ersten Schritt tatsächlich nur eine einzige Methode: ValidateUser. Diese wird vom Login-Control aufgerufen:

public override bool ValidateUser(string username, string password)
{
   bool returnValue = false;
   using (SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["XYZ"].ConnectionString))
   {
      using (SqlCommand cmd = new SqlCommand())
      {
         cmd.Connection = connection;
         cmd.CommandType = CommandType.Text;
         cmd.CommandText = "Select Count(*) From KundenTabelle Where Login = @username AND Passwort = @password";
         cmd.Parameters.AddWithValue("@username", username);
         cmd.Parameters.AddWithValue("@password", password);
         connection.Open();
         object result = cmd.ExecuteScalar();
         if (result != null)
            if ((int)result == 1)
               returnValue = true;
      }
   }
   return returnValue;
}

Dann muss natürlich noch das Login-Control irgendwo platziet werden:

Darunter habe ich zu Testzwecken noch ein LoginStatus-Control platziert, damit man gleich sieht ob man angemeldet ist oder nicht ...

Und last but not least muss der eigene MemberShipProvider natürlich noch in der Web.config registriert werden:

"MyMembershipProvider" userIsOnlineTimeWindow="20">
   
      "MyMembershipProvider" type="MyMembershipProvider"/>
   

Zudem darf man nicht vergessen die Authentication-Art von Windows auf Forms umzustellen:

"Forms">
    "AutoDetect" protection="All" slidingExpiration="true"
   defaultUrl="~/Default.aspx" loginUrl="~/Default.aspx" />

Fertig

War einfach, oder? Für alle die es nicht glauben, hier ein Beispielprojekt (benötigt das .NET Framework 2.0 und SQL Server Express):

MyMembershipProvider.zip (187,74 KB)

Kommentare

  1. Norbert schrieb am Mittwoch, 21. Dezember 2005 18:23:00 Uhr:

    Nette Sache, Thomas. Kann man sicher irgendwann mal brauchen, wenn nicht sofort ;-)
  2. frostvip schrieb am Mittwoch, 20. Dezember 2006 11:24:00 Uhr:

    Feine Sache, genau dass habe ich gebraucht...naja fast. Es müsste auf dem normalen sql server 2005 laufen und ich müsste über ein Registrierungsformular, Daten wie name,firma, usw... abspeichern können. Gibts dafür auch so ein schönes tutorial? :-)

    vielen dank soweit
  3. Thomas schrieb am Mittwoch, 20. Dezember 2006 12:30:00 Uhr:

    Von mir nicht - aber das sind Sachen, die du mit ein wenig Grundwissen von ADO.NET, d.h. Datenbankzugriff und WebControls, d.h. TextBoxen selbst hinbekommen solltest.
  4. frostvip schrieb am Mittwoch, 20. Dezember 2006 19:19:00 Uhr:

    ich habe nur in der webconfig den connecstring ausgetauscht (der stimmt übrigens hab es in einem anderen projekt getestet) und jetzt bekomme ich die fehlermeldung beim ausführen der anmeldevorgangs: Parserfehlermeldung: Der Typ "MyMembershipprovider" konnte nicht geladen werden.
  5. Flo schrieb am Donnerstag, 26. April 2007 19:51:00 Uhr:

    Hallo Thomas.
    Ausgezeichnetes Beispiel. Verständlich erklärt und in maximal 5 Minuten verstanden und nachprogrammiert. Habe sehr lange nach der richtigen Verwendung des Membershipproviders gesucht.
    Der Beitrag ist um Klassen besser als der aus der MSDN Libary bezüglich MembershipProvider :)

    Weiter so!
  6. olla - ist wirklich gut gelungen! schrieb am Dienstag, 7. August 2007 23:01:00 Uhr:

    allerdings... nun ich habe versucht das mit vb.net nachzumachen... also die klasse abzuleiten und die function zu überschreiben ist ja fix gemacht.
    jedoch... ich kann in der webconfig die default provider eigenschaft nicht umsetzen! du hast deinem beispiel ja kein projectfile oder solution beigelget, aber der myprovider wird aus dem verzeichniss app_code compiliert. wie is es bei vb? ich habe ebenso eine klasse in einer einzelnen datei jedoch wird sie nicht compiliert...
    auch mit einem namespace der des aktuellen projekts lässt sich das nicht händeln .
    die webconfig findet das ding einfach nicht! ganz schöner gammel das! irgendwie scheint mir die einstellung in der webconfig doch unausgereift wenn diese stringparameter nicht akzeptiert werden!
  7. Thomas schrieb am Dienstag, 7. August 2007 23:09:00 Uhr:

    Von C# zu VB.NET sollte es hier keinen Unterschied geben. Nutzt du ein Web- oder ein Web-Application-Project?
  8. so abAnuh! schrieb am Mittwoch, 8. August 2007 01:39:00 Uhr:

    also nun funzt dat auch!
    da ich noch so überhaupt nicht fit in dieser asp geschichte bin, fällt mir dat wohl noch ein bissel schwer.
    der string in der webconfig muss auf das aktuelle startprojekt verweisen - wenn man auch noch namespaces setzt dann halt komplett runter...und wie die assambly heißt is wohl komplett wurscht.
    das ist ja nun doch anders als wenn man beispielsweise connstr in der webconfig setzen will und den filestring übergibt.
    da es in der instanzierung von webconfig wohl nicht richtig debuged wird waren die fehlermeldungen auch nicht aussagekräftig.
    nun in jedemfall danke ich dir - ich lerne es schon noch
  9. daniel schrieb am Mittwoch, 19. September 2007 21:03:00 Uhr:

    Super! Funktioniert sofort. Beste im Netz verfügbare Erklärung :)
  10. Alexia schrieb am Mittwoch, 27. Januar 2010 15:00:00 Uhr:

    Bei mir geht es nicht!!
    Es kommt immer:
    Parserfehlermeldung: Der Typ "MyMembershipProvider" konnte nicht geladen werden.
    Woran kann das liegen?
  11. Michael schrieb am Montag, 26. April 2010 17:37:00 Uhr:

    Danke für das Beispiel!
    Und für Alexia, für den Fall, daß es noch aktuell ist:
    Ich würde vorschlagen, den Typ in der web.config mal mit dem Namespace zu qualifizieren, also

    type="der_namespace.MyMembershipprovider"/

  12. Tihomir schrieb am Donnerstag, 18. August 2011 23:48:00 Uhr:

    Coole Sache, ich sehe bloß, dass der Eintrag vom Dezember 2005 ist. Hat sich denn seitdem viel geändert?
  13. Thomas schrieb am Freitag, 19. August 2011 09:16:00 Uhr:

    Das kommt ganz darauf an ... wenn du mit WebForms arbeitest und die vorhandenen Controls für Login etc. benutzen willst, dann nicht. Wenn du z.B. mit ASP.NET MVC arbeitest, dann brauchst du keinen Membership-Provider mehr.


« Zurück  |  Weiter »