13.2 »Wer darf was?« innerhalb von ASP.NET entscheiden
 
Wenn die Anwender, die sich auf Ihrer Website einloggen, nicht über ein Windows-Benutzerkonto verfügen, müssen Sie ein eigenes System für die Authentifizierung entwickeln. Außerdem müssen Sie dann auch den Bereich der Autorisierung selbst abdecken, denn für Anwender ohne Windows-Benutzerkonto sind natürlich auch keine Einträge in den NTFS-Dateizugriffslisten vorhanden.
ASP.NET unterstützt Sie bei der Realisierung eigener Verfahren für die Authentifizierung und Autorisierung. Für die Authentifizierung verwenden Sie die so genannte formularbasierte Authentifizierung.
Die Bezeichnung formularbasierte Authentifizierung ist nicht sehr klar, denn schließlich müssen Sie auch bei den Methoden Windows-Standard und Windows-Digest jeweils in einem Formular Ihre Zugangsdaten eingeben. Der Unterschied besteht darin, dass Sie dieses Formular nicht selbst erstellt haben, sondern dass es vom Browser automatisch generiert wird. Bei der formularbasierten Authentifizierung hingegen erstellen Sie eine eigene aspx-Seite mit Eingabemöglichten für Anwendernamen und Passwort und werten diese Angaben anschließend selbst aus.
Ausgehend von diesem Formular führen Sie selbstständig die Authentifizierung durch. Bei erfolgreicher Authentifizierung wird ein Cookie erzeugt, das bei weiteren Anforderungen wie ein Pass funktioniert, der zum Aufruf geschützter Ressourcen berechtigt. Die Gültigkeit dieses Cookies läuft nach einer vordefinierten Zeit ab. Es ist auch möglich, persistente Cookies zu erzeugen, so dass der Anwender bei künftigen Aufrufen bereits authentifiziert ist.
Mit Hilfe von Einträgen in der Datei web.config legen Sie außerdem fest, welcher Anwender auf welche Dateien zugreifen darf. An einem einfachen Beispiel sollen die grundlegenden Schritte durchgespielt werden.
Unter dem Anwendungsverzeichnis ASPdotNETBuch legen Sie ein neues Verzeichnis projekt2020 an. Die Dateien in diesem Verzeichnis soll nur der Anwender ML aufrufen können. Die Datei infoProjekt2020.aspx im Verzeichnis projekt2020 enthält die geschützten Informationen. In der Datei loginProjekt2020.aspx stellen Sie ein Anmeldeformular zur Verfügung, das auch die Authentifizierung übernimmt. Wenn jemand direkt den URL zur geschützten Datei infoProjekt2020.aspx aufruft, soll er auf die Login-Seite umgeleitet werden. Wenn das Login erfolgreich war, soll die gewünschte Seite angezeigt werden, ansonsten erscheint eine Fehlermeldung.
Dieses Mini-Projekt realisieren Sie in fünf Schritten, die im Anschluss genauer vorgestellt werden:
1. Sie konfigurieren die IIS so, dass ein anonymer Zugriff möglich ist (denn die Authentifizierung erledigt ASP.NET).
2. Sie erstellen die zu schützende Datei infoProjekt2020.aspx im Verzeichnis projekt2020.
3. Im Anwendungsverzeichnis der Anwendung ASPdotNETBuch richten Sie in der Datei web.config die formularbasierte Authentifizierung ein.
4. Im Verzeichnis projekt2020 legen Sie eine eigene web.config an, die die Zugriffsrechte für dieses Verzeichnis festlegt.
5. Sie erstellen die Datei loginProjekt2020.aspx im Verzeichnis projekt2020.
13.2.1 Die IIS für formularbasierte Authentifizierung einrichten
Bei der formularbasierten Authentifizierung führen Sie selbst und nicht die IIS die Authentifizierung durch. Was also soll es bei den IIS zu konfigurieren geben? Ganz einfach: Sie müssen sicherstellen, dass die IIS auch jede Anfrage durchlassen, dass also ein anonymer Zugriff möglich ist und zwar auch auf das Verzeichnis, dessen Inhalte geschützt werden sollen. Über Start • Einstellungen • Systemsteuerung • Verwaltung • Internetdienste-Manager können Sie die IIS konfigurieren. Bei den Eigenschaften der Anwendung ASPdotNETBuch überprüfen Sie, ob auf der Registerkarte Verzeichnissicherheit im Bereich Steuerung des anonymen Zugriffs und der Authentifizierung ein anonymer Zugriff möglich ist. Im Dialogfeld Authentifizierungsmethoden darf nur die Option Anonyme Anmeldung selektiert sein (siehe dazu auch Abbildung 13.1). Die gleiche Überprüfung nehmen Sie für das Verzeichnis projekt2020 vor.
13.2.2 Eine zu schützende Datei erstellen
Die Datei, die nur der Anwender ML aufrufen dürfen soll, liegt im Verzeichnis projekt2020 und heißt infoProjekt2020.aspx. Diese Datei hat beispielsweise diesen Inhalt:
<!-- infoProjekt2020.aspx -->
<%@ Page Language="VB" Debug="True" Strict="True" %>
<html><body><head><title>Info Projekt 2020</title>
</head>
<h3>Info Projekt 2020</h3>
Gesicherte Informationen
</body></html>
An dieser Datei ist bemerkenswert, dass nichts an ihr darauf hinweist, dass sie in irgendeiner Form geschützt sein soll. Diesen Schutz steuern Sie über die beiden web.config-Dateien.
13.2.3 In der Datei web.config die formularbasierte Authentifizierung einrichten
Im Stammverzeichnis der Webanwendung ASPdotNETBuch legen Sie eine web.config mit diesem Inhalt an:
<configuration>
<system.web>
<authentication mode="Forms" >
<forms
name="myWebApp2020"
loginUrl="projekt2020/loginProjekt2020.aspx"
protection="All"
timeout="10" />
</authentication>
</system.web>
</configuration>
Das Element authentication kann nur im Stammverzeichnis einer Webanwendung verwendet werden, nicht in Unterverzeichnissen wie beispielsweise dem Verzeichnis projekt2020. Über das Attribut mode="Forms" legen Sie die formularbasierte Authentifizierung fest. Mit dem untergeordneten Element forms machen Sie genauere Angaben zur Authentifizierung. name="myWebApp2020" legt den Namen des zu verwendenden Cookies fest. loginUrl="projekt2020/loginProjekt2020.aspx" nennt den URL des Login-Formulars relativ zum Stammverzeichnis der Webanwendung. protection="All" gibt an, dass zum Schutz des Cookies sowohl eine Datenüberprüfung als auch eine Verschlüsselung zum Einsatz kommt. Das ist zugleich die Default-Einstellung. Mit timeout="10" geben Sie an, dass die Gültigkeit des Cookies nach zehn Minuten abläuft.
13.2.4 In einer weiteren web.config-Datei die Autorisierung einrichten
Während Sie in der web.config für das Webanwendungs-Stammverzeichnis lediglich die Authentifizierungsmethode eingerichtet haben, legen Sie in der web.config-Datei, die im Verzeichnis projekt2020 liegt, die Regeln für die Autorisierung fest.
<configuration>
<system.web>
<authorization>
<allow users="ML" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
Innerhalb des authorization-Elements legen Sie mit dem allow-Element diejenigen Anwender und Gruppen fest, die zugreifen dürfen. Dem Attribut users übergeben Sie eine kommaseparierte Liste der berechtigten Anwender. Mit dem Attribut roles könnten Sie berechtigte Gruppen definieren.
Das Element deny legt fest, wer abgewiesen wird. deny users="*" verweigert prinzipiell allen Anwendern den Zugriff, außer ML. ASP.NET wendet jeweils diejenige Regel an, die als Erste auf einen Anwender zutrifft.
13.2.5 Die Datei mit dem Login-Formular erstellen
Als Letztes erstellen Sie die Datei mit dem Anmeldeformular. So könnte sie aussehen. Erläuterungen schließen sich an.
<!-- loginProjekt2020.aspx -->
<%@ Page Language="VB" Debug="True" Strict="True" %>
<%@ Import Namespace="System.Web.Security" %>
<script runat="server">
Sub btnLogin_Click (ByVal Sender As Object, _
ByVal E As EventArgs )
Dim validUser As String = "ML"
Dim validPass As String = "uhuahaoho"
If (txtName.Text = validUser And _
txtPass.Text = validPass) Then
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false)
Else
lblErgebnis.Text = "Kein Zugang möglich!"
End If
End Sub
</script>
<html><body><head><title>Login Projekt 2020</title>
</head>
<h3>Login Projekt 2020</h3>
<form runat="server" >
Name<br>
<asp:TextBox runat="server"
TextMode="SingleLine"
id="txtName" /><br>
Passwort<br>
<asp:TextBox runat="server"
TextMode="Password"
id="txtPass" />
<br>
<asp:Button runat="server"
Text="Login"
id="btnLogin"
onClick="btnLogin_Click" /><br>
<br>
<asp:Label
id="lblErgebnis"
runat="server"
/>
</form></body></html>
Der Code dieser Seite enthält wenig Überraschungen. Die Authentifizierung erfolgt innerhalb dieser Seite, indem mit hart codierten Werten verglichen wird. In der Praxis werden andere Methoden zum Einsatz kommen. Sie können die Zugangsdaten aus Datenbanken abrufen oder auch in einer web.config ablegen. Weiter unten lernen Sie einige dieser Methoden näher kennen. Zur Demonstration reicht an dieser Stelle dieses hart codierte Verfahren aus.
Die einzige erklärungsbedürftige Zeile ist
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false).
Der Sinn dieses Befehls erschließt sich am leichtesten, wenn man das kleine Projekt einmal im Zusammenhang testet. Rufen Sie im Browser nicht die Login-Seite direkt, sondern die geschützte Seite infoProjekt2020.aspx auf. Anschließend erscheint nicht die Info-Seite, sondern das Login-Formular. Das ist das Resultat der Zusammenarbeit der beiden web.config-Dateien. Die web.config aus dem Verzeichnis projekt2020 meldet, dass die Inhalte aus diesem Verzeichnis geschützt sind. Nur der Anwender ML hat Zugang und die aktuelle Anfrage stammt von einem anonymen Anwender. Die web.config aus dem Stammverzeichnis weiß nun, wie zu verfahren ist. Der Anwender soll sich mit der formularbasierten Methode authentifizieren. Der URL des Login-Formulars lautet projekt2020/loginProjekt2020.aspx. Also ruft ASP.NET diese Seite auf und statt der Info-Seite erscheint das Login-Formular. Gleichzeitig merkt sich die Login-Seite aber, welche Seite ursprünglich angefordert wurde. In Abbildung 13.7 ist die Arbeitsweise erkennbar.
Hier klicken, um das Bild zu Vergrößern
Abbildung 13.7 Die Login-Seite wird automatisch aufgerufen, wenn eine geschützte Seite aufgerufen wird.
Im URL des Browsers sehen Sie, dass die Login-Seite mit einem Parameter ReturnUrl aufgerufen wurde, der die ursprüngliche Seite nennt. Wenn Sie sich als Anwender ML mit dem korrekten Passwort einloggen, zeigt der Browser anschließend die Info-Seite an. Damit erschließt sich auch endlich der Sinn dieser Code-Zeile:
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false).
Dieser Befehl arbeitet im Prinzip so wie Response.Redirect. Bei erfolgreicher Authentifizierung wird zu der ursprünglich angeforderten Seite weitergeleitet. Über den automatisch generierten ReturnUrl-Parameter, mit dem die Login-Seite aufgerufen wurde, weiß RedirectFromLoginPage, zu welcher Seite weitergeleitet werden soll. Im ersten Parameter wird der Name des Anwenders übergeben. Der zweite Parameter gibt an, ob das zu erzeugende Cookie persistent sein soll oder nicht.
Wenn Sie den Browser schließen und wieder öffnen, können Sie testen, was passiert, wenn Sie die Login-Seite direkt aufrufen. Bei erfolgreichem Login erscheint möglicherweise die Meldung Serverfehler in der Anwendung '/ASPdotNETBuch'. Die Ressource kann nicht gefunden werden. Und als angeforderter URL wird /ASPdotNETBuch/default.aspx angegeben.
Der Befehl RedirectFromLoginPage verursacht diesen Fehler, wenn die Seite /ASPdotNETBuch/default.aspx nicht existiert. Wenn Sie die Login-Seite direkt aufrufen, dann ruft RedirectFromLoginPage anschließend automatisch die Seite default.aspx auf. Beim operativen Einsatz sollte eine Seite mit diesem Namen also vorhanden sein.
13.2.6 Die Zugangsdaten in der web.config speichern
Die Zugangsdaten der Anwender mit Zugangsberechtigung können Sie auch direkt in der Datei web.config ablegen. Diese Information gehört in den Bereich Authentifizierung. Für das Beispiel bearbeiten Sie also die web.config-Datei im Stammverzeichnis der Anwendung. Folgendermaßen könnten Sie den Anwendern ML, TL und KF Zugang zum geschützten Bereich gewähren:
<configuration>
<system.web>
<authentication mode="Forms" >
<forms
name="myWebApp2020"
loginUrl="projekt2020/loginProjekt2020.aspx"
protection="All"
timeout="10">
<credentials passwordFormat="Clear">
<user name="ML" password="uhuahaoho" />
<user name="TL" password="Tl89Uixn" />
<user name="KF" password="iiuQ$563" />
</credentials>
</forms>
</authentication>
</system.web>
</configuration>
Innerhalb des forms-Elements fügen Sie ein credentials-Element hinzu. Im credentials-Element listen Sie in user-Elementen die Anwender auf, die irgendeine Form von Zugangsberechtigung haben.
Tipp Zur Erinnerung: Wozu diese Anwender berechtigt sind, regelt die andere web.config-Datei im Verzeichnis projekt2020. Wenn beispielsweise nur ML und TL den Zugang zu projekt2020 haben sollen und KF irgendwelche Rechte in anderen Verzeichnissen hat, die im Rahmen dieses Beispiels nicht behandelt wurden, dann muss die web.config-Datei im Verzeichnis Projekt2020 im authorization-Abschnitt diesen Eintrag enthalten:
<allow users="ML, TL" />
|
In der Datei loginProjekt2020.aspx müssen Sie schließlich die Prozedur btnLogin_Click so anpassen, dass nicht mehr mit den hart codierten Werten, sondern mit den Einträgen aus der web.config verglichen wird. Für diese Aufgabe stellt die Klasse FormsAuthentication die Methode Authenticate zur Verfügung, mit der sich folgende Form ergibt:
Sub btnLogin_Click (ByVal Sender As Object, _
ByVal E As EventArgs )
If FormsAuthentication.Authenticate _
(txtName.Text, txtPass.Text) Then
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false)
Else
lblErgebnis.Text = "Kein Zugang möglich!"
End If
End Sub
Wenn Sie jetzt den Browser schließen, wieder öffnen und Tests durchführen, indem Sie direkt die geschützte Info-Seite aufrufen, ergibt sich dieses Bild: ML und TL können nach erfolgreichem Login die Info-Datei aufrufen. Ein unbekannter Anwender, z. B. XY, erhält den Hinweis Kein Zugang möglich! KF aber kann die Info-Datei nicht anzeigen, erhält aber auch nicht den Hinweis Kein Zugang möglich! Dahinter steckt folgende Logik: KF kann sich authentifizieren, also ergibt der Aufruf von FormsAuthentication.Authenticate den Wert true. Dementsprechend wird mit RedirectFromLoginPage zur ursprünglich angeforderten Info-Seite zurückgeleitet. Dort aber wird geprüft, ob der erfolgreich authentifizierte Anwender KF denn auch zum Zugriff autorisiert ist. Ergebnis: Nein und damit wird das Prozedere an die Authentifizierung zurückgegeben und die Login-Seite wird neu aufgerufen. Und weil die Seite neu aufgerufen wird, erscheint auch kein Hinweis von der Art Kein Zugang möglich!
Unser Programm ist an dieser Stelle offenkundig noch nicht ganz perfekt. Es wäre sinnvoll, wenn KF beispielsweise den Hinweis bekäme: KF ist für den Zugriff auf projekt2020 nicht autorisiert. Der nächste Abschnitt realisiert eine entsprechende Möglichkeit.
13.2.7 Den authentifizierten Anwender erkennen und ein Logout ermöglichen
Wenn man sich den Code für das Login noch einmal genau ansieht, stellt man fest, dass an einer Stelle eigentlich ein Kurzschluss passiert. Und zwar zwischen diesen beiden Code-Zeilen:
If FormsAuthentication.Authenticate _
(txtName.Text, txtPass.Text) Then
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false)
' ...
Die erste Zeile führt die Authentifizierung durch. Wenn der Anwender sich authentifizieren konnte, wird die nächste Zeile ausgeführt. Hier wird der Anwender zur ursprünglich angeforderten Seite weitergeleitet. Wo aber findet eigentlich die Überprüfung statt, ob der Anwender für diese Seite auch autorisiert ist? Diese Überprüfung findet nicht im Rahmen dieses Codes statt. ASP.NET überprüft das in dem Moment, in dem die Seite unter dem Namen des Anwenders aufgerufen wird. In diesem Moment erst entdeckt ASP.NET, dass der Anwender KF sich zwar ordnungsgemäß authentifiziert hat, für diese Seite aber nicht autorisiert ist und damit wird an das Login-Formular zurückverwiesen.
Wenn Sie den authentifizierten, aber nicht autorisierten Anwender entsprechend benachrichtigen möchten, besteht eine Möglichkeit darin, innerhalb des Login-Formulars zu überprüfen, ob der Anwender bereits bekannt ist. Wenn der Anwender bereits authentifiziert ist, teilen Sie ihm mit, dass er für den Aufruf der Ressource nicht autorisiert ist. Zusätzlich bieten Sie die Option an, sich auszuloggen und unter einem anderen Namen neu anzumelden. Das folgende Skript realisiert eine entsprechende Möglichkeit.
<!-- loginProjekt2020b.aspx -->
<%@ Page Language="VB" Debug="True" Strict="True" %>
<%@ Import Namespace="System.Web.Security" %>
<script runat="server">
Sub Page_Load (ByVal Sender As Object, _
ByVal E As EventArgs)
If User.Identity.IsAuthenticated Then
Dim s As String
s = "Hallo, "
s &= User.Identity.Name
s &= "! Sie sind bereits eingeloggt. Aber "
s &= "für die angeforderte Ressource sind Sie "
s &= "nicht autorisiert. Wenn Sie möchten, "
s &= "können Sie sich hier ausloggen und erneut "
s &= "anmelden."
lblErgebnis.Text = s
btnLogout.Visible = true
End If
End Sub
Sub btnLogout_Click (ByVal Sender As Object, _
ByVal E As EventArgs )
FormsAuthentication.SignOut()
Response.Clear()
Response.Redirect (Request.UrlReferrer.ToString())
End Sub
Sub btnLogin_Click (ByVal Sender As Object, _
ByVal E As EventArgs )
If FormsAuthentication.Authenticate _
(txtName.Text, txtPass.Text) Then
FormsAuthentication.RedirectFromLoginPage _
(txtName.Text, false)
Else
lblErgebnis.Text = "Kein Zugang möglich!"
End If
End Sub
</script>
<html><body><head><title>Login Projekt 2020</title>
</head>
<h3>Login Projekt 2020</h3>
<form runat="server" >
Name<br>
<asp:TextBox runat="server"
TextMode="SingleLine"
id="txtName" /><br>
Passwort<br>
<asp:TextBox runat="server"
TextMode="Password"
id="txtPass" />
<br>
<asp:Button runat="server"
Text="Login"
id="btnLogin"
onClick="btnLogin_Click" /><br>
<br>
<asp:Label
id="lblErgebnis"
<$tab> runat="server"
/><br>
<asp:Button runat="server"
Text="Logout"
id="btnLogout"
onClick="btnLogout_Click"
Visible="false" />
</form></body></html>
Das Login-Formular hat zusätzlich die Prozedur Page_Load erhalten. Die Prozedur überprüft mit dem Aufruf von User.Identity.IsAuthenticated, ob der Anwender bereits eingeloggt ist. Wenn ja, wird er benachrichtigt, dass er unter dem Namen, der mit User.Identity.Name ermittelt wird, zwar bereits authentifiziert ist, aber für den Aufruf dieser Ressource nicht autorisiert ist. Die neu hinzugefügte Schaltfläche für ein Logout wird sichtbar gemacht.
Diese Logout-Schaltfläche ist die zweite Neuerung für das Login-Formular. Ihre Eigenschaft Visible steht zunächst auf false. Nur in dem soeben geschilderten Fall wird die Schaltfläche dargestellt. Beim Anklicken der Schaltfläche wird die Prozedur btnLogout_Click ausgeführt. Der Befehl FormsAuthentication.SignOut() entfernt den Authentifizierungs-Cookie. Response.Clear() löscht den Ausgabepuffer und anschließend wird erneut zu der Seite umgeleitet, für die keine Autorisierung bestand. Resultat: Das Login-Formular wird erneut aufgerufen und der Anwender kann sich hier unter dem Namen eines Users einloggen, der über die entsprechende Berechtigung verfügt. Ein erfolgreiches Login führt damit zur geschützten Seite.
13.2.8 Passwörter in der web.config in verschlüsselter Form speichern
Bislang haben Sie die Passwörter in der Datei web.config im Klartext gespeichert. ASP.NET bietet zusätzlich die Möglichkeit, die Passwörter in verschlüsselter Form zu hinterlegen. Dafür stehen die beiden Algorithmen MD5 und SHA1 zur Verfügung. Diese Algorithmen verschlüsseln einen String so, dass aus dem resultierenden String nicht der Ausgangsstring zurückberechnet werden kann. Damit sichern Sie Ihre Applikation zusätzlich gegen Missbrauch ab. Selbst wenn jemand Einblick in die Datei web.config erhielte, könnte er sich mit Hilfe dieser Informationen nicht einloggen. Um dieses Verfahren verwenden zu können, müssen Sie zunächst den verschlüsselten String erzeugen. Dafür bietet die Klasse FormsAuthentication eine Methode mit dem sprechenden Namen HashPasswordForStoringInConfigFile.
Sie erstellen ein Formular, in dem Sie das gewünschte Passwort eingeben. Anschließend berechnet das Formular mit Hilfe der genannten Funktion den verschlüsselten Ausdruck. Diesen kopieren Sie in den credentials-Abschnitt Ihrer web.config-Datei. In der web.config-Datei geben Sie außerdem noch das verwendete Verschlüsselungsformat an. Die Datei securePass.aspx enthält das Formular zum Erzeugen der verschlüsselten Werte. Abbildung 13.8 zeigt das Formular in Aktion.
<!-- securePass.aspx -->
<%@ Page Language="VB" Debug="True" Strict="True" %>
<%@ Import Namespace="System.Web.Security" %>
<script runat="server">
Sub Page_Load (ByVal Sender As Object, _
ByVal E As EventArgs)
If IsPostBack Then
Dim s As String
s = "<b>MD5:</b> "
s &= FormsAuthentication. _
HashPasswordForStoringInConfigFile _
(txtPass.Text, "md5")
s &= "<br>"
s &= "<b>SHA1:</b> "
s &= FormsAuthentication. _
HashPasswordForStoringInConfigFile _
(txtPass.Text, "sha1")
lblErgebnis.Text = s
End If
End Sub
</script>
<html><body><head><title>Passwort verschlüsseln</title>
</head>
<h3>Passwort verschlüsseln</h3>
<form runat="server" >
Passwort
<asp:TextBox runat="server"
id="txtPass"
TextMode="SingleLine" /><br><br>
<asp:Button runat="server"
id="btnOK"
Text="Verschlüsseln" /><br><br>
<asp:Label runat="server"
id="lblErgebnis" />
</form></body></html>
Wenn Sie die Passwörter für die Anwender ML, TL und KF auf diese Weise verschlüsseln, ergibt sich für den credentials-Abschnitt in der web.config-Datei diese Form:
<credentials passwordFormat="MD5">
<user name="ML"
password="F6BA5F4086DEE6D6ED8FF8E6B8AC47EE" />
<user name="TL"
password="6DB9114AF9335A8ABBD699AEF5CBBDDF" />
<user name="KF"
password="249BE279FC10569C3AEAC1819D3D1BC6" />
</credentials>
Im Login-Formular selbst müssen Sie keine Änderungen vornehmen.
Hier klicken, um das Bild zu Vergrößern
Abbildung 13.8 Passwörter können in der web.config-Datei in verschlüsselter Form gespeichert werden.
| Achtung Falls Sie beim Testen feststellen sollten, dass Sie nicht mehr wissen, wie das Passwort für einen der Anwender geheißen hat (sie können es jetzt ja auch nicht mehr nachschlagen), dann gibt es keinen Weg, dieses Passwort aus dem MD5-Wert zurückzuberechnen. Ihnen bleibt dann nur die Möglichkeit, ein komplett neues Passwort zu verwenden und die web.config für das neue Passwort einzurichten.
|
|
