Ein paar Minuten später
Das ist es im Wesentlichen. Um sich zu erinnern, dass ein Benutzer sich angemeldet hat, gibt er dem Benutzer ein Token, das er bei seiner nächsten Anfrage vorlegen muss. Dies wird normalerweise dadurch erreicht, dass der Server dem Browser mitteilt, dieses Token in einem Cookie zu speichern.
Die Art der Übergabe der Anmeldeinformationen an den Server und die Art des zurückgegebenen Tokens hängt von der verwendeten Authentifizierungsmethode ab.
Die einfachste HTTP-Standardauthentifizierung wird von den meisten Webserverimplementierungen bereitgestellt. Dadurch öffnet Ihr Browser das vertraute Anmeldedialogfeld. Das "Token" ist einfach Ihr Klartext Benutzername und Passwort base64 codiert. Nicht besonders sicher.
Ein Server kann auch Digestauthentifizierung bereitstellen, wodurch die Übertragung der eigentlichen Anmeldeinformationen vermieden wird - stattdessen generiert der Client einen Hashwert von ihre Anmeldeinformationen mit einem Server generiert Salz. Es wurde entwickelt, um Passwort-Sniffing und Replay-Angriffe zu verhindern.
Für maximale Flexibilität und Kontrolle entscheiden sich die meisten Standorte dafür, die Autorisierung in der Anwendungsschicht und nicht in der HTTP-Transportschicht zu implementieren. Dies bietet eine größere Auswahl an Sicherheitsoptionen. Jede Site, die nach Anmeldeinformationen auf einer Webseite fragt (anstatt im Anmeldedialogfeld des Browsers), verwendet eine benutzerdefinierte Autorisierungsmethode.
Benutzerdefinierte Methoden variieren stark in ihrer anfänglichen Interaktion, aber sie führen fast immer dazu, dass dem Benutzer ein Sitzungscookie mit einem zufällig generierten Bezeichner gegeben wird. Der Browser präsentiert dann das Cookie automatisch mit jeder nachfolgenden Anfrage. Die Webanwendung überprüft den Cookie-Wert, um sicherzustellen, dass er noch gültig ist.
Es ist auch möglich, die Autorisierung an eine vertrauenswürdige dritte Partei zu übergeben, im Allgemeinen, um eine Art von Single-Signon-Service bereitzustellen. Wenn Sie in solchen Fällen feststellen, dass ein Benutzer nicht authentifiziert ist, leiten Sie diese an den Authentifizierungsanbieter ab. Sie authentifizieren sie und sie werden Ihnen mit einer Art Token zurückgegeben, die Sie beim Provider bestätigen. Shibboleth ist ein Beispiel dafür. Sie haben sich auch auf dieser Site angemeldet, indem Sie eine ähnliche Methode verwenden, die von OpenID
verwendet wirdHier sind einige nette Antworten von eine ähnliche Frage
Andere Antworten in dieser Frage bieten noch mehr Links, um Ihre Ausbildung abzurunden!
Das ist eine ziemlich allgemeine Frage. Alles, was Sie tun, ist, eine Art von Anmeldeinformationen mit der Site selbst zu erstellen. Wenn wir die einfache Version nehmen, geben Sie einen Benutzernamen und ein Passwort ein; Das heißt, Sie identifizieren sich mit der Website und zeigen dann ein Geheimnis, das Sie und die Website teilen, die niemand sonst weiß (wir hoffen). Das bestätigt, dass Sie authentisch die Person mit diesem Benutzernamen sind und wir sagen, Sie haben sich authentifiziert .
Sobald Sie dies getan haben, gibt es einige Designentscheidungen, die der Website-Designer treffen muss. Die meisten Leute wollen sich nicht für jede Seite anmelden, daher möchte die Website ein paar Informationen, einen Credential , an Ihrem Ende speichern. Das bedeutet, dass es dir sagen kann, dass du immer noch bist. Oft ist dies, wie Sie sagen, ein "Cookie", der nichts anderes ist als eine winzige Textdatei, die mit der URL der Website benannt ist. Diese Datei wird vom Browser gespeichert.
Auf vielen Websites, wie beim Banking, möchten Sie auch sicherstellen, dass die ausgetauschten Daten nicht von Dritten abgefangen werden können. Wenn dies der Fall ist, richten Sie eine sichere Verbindung mithilfe eines Protokolls ein, das als SSL oder TLS bezeichnet wird. Was dies zur Basisverbindung hinzufügt, ist ein Austausch von Informationen, der einen Sitzungsschlüssel festlegt. Dieser Sitzungsschlüssel wird dann verwendet, um die Kommunikation zu verschlüsseln. In der Regel passiert dies, bevor Sie den Benutzernamen und das Passwort austauschen, so dass Ihr Passwort auch für böswillige Dritte nicht sichtbar ist.
Unter dem Deckblatt sendet die Website Ihrem Browser bei der Herstellung einer sicheren Verbindung einen Block formatierter Daten, die als x509-Zertifikat bezeichnet werden. Dies ist eine andere Form der Authentifizierung; Das Zertifikat wurde von einem Aussteller (der Zertifizierungsstelle oder "CA") signiert und der Browser kann gespeicherte Daten über die Zertifizierungsstellen verwenden, um sicherzustellen, dass das Zertifikat authentisch ist.
Dies hängt vollständig von der Implementierung der Website ab. Auch die Verwendung von Cookies ist nicht zwingend, aber sehr üblich.
In den meisten Fällen passiert jedoch so etwas:
Sie sind jetzt eingeloggt. Sie bleiben während des Rests der Sitzung angemeldet:
Wenn Sie sich bei einer Website anmelden, werden zunächst Ihre Anmeldeinformationen authentifiziert. Wenn Ihre Anmeldeinformationen übereinstimmen, wird etwas in die Sitzung (auf dem Server) geschrieben, um zu verfolgen, wer Sie sind, damit Sie auf Ihre Daten zugreifen können, ohne sich erneut anmelden zu müssen. Dies ist offensichtlich nutzlos auf dem Webserver, es sei denn, der Client kann bei jeder Anfrage Informationen darüber bereitstellen, wer es ist. Beachten Sie, dass die "Sitzung" normalerweise vollständig auf dem Webserver verwaltet wird, wobei der Client nur über einen Schlüssel verfügt, der den Zugriff auf die Sitzung ermöglicht.
Denken Sie daran, dass HTTP selbst ein Stateless-Protokoll ist. Der HTTP-Standard enthält keine Methode für HTTP-Anforderungen, um einen Status zwischen einzelnen HTTP-Anforderungen beizubehalten oder beizubehalten. Daher wird der Status normalerweise vollständig auf dem Server gespeichert und Sie benötigen lediglich eine Methode, mit der der Client ermitteln kann, zu welcher Sitzung die aktuelle HTTP-Anforderung gehört.
Die zwei gebräuchlichen Methoden sind:
JSESSIONID -Cookie), um ein Hash-Authentifizierungstoken zu speichern, das die Websitzung erfolgreich nachschlägt, oder ;jsessionid=.... " zu enden. Somit endet jede Anfrage, jedes HTTP GET und POST (und der Rest) mit dieser Zeichenfolge. Somit wird bei jeder Anfrage des Clients die Sitzungs-ID dem Webserver zur Verfügung gestellt, so dass der permanente Status für diesen Client schnell nachgeschlagen werden kann, wodurch HTTP wie ein statusfähiges Protokoll agieren kann.
Welche Informationen werden beim Anmelden an den Server gesendet? Welche Informationen Sie auch auf dem Anmeldeformular angegeben haben. Einige Webserver verfolgen auch die TCP / IP-Adresse, von der die Anfrage kam, um Session-Hijacking-Angriffe zu vermeiden. Dies sind normalerweise alle Informationen, die vom Server benötigt werden.
Wenn Sie es Ihrem Browser nicht erlauben, Cookies zu speichern, müssen Sie sich bei jedem Öffnen des Browsers beim Webserver anmelden und zunächst die Webseite des Servers öffnen. Wenn Sie jedoch zulassen, dass Ihr Browser Cookies speichert, können Sie auf vielen Servern die Option zum Speichern des Cookies (das heißt, nicht nur zum Verwenden eines Sitzungscookies) verwenden, sodass jedes Mal, wenn Sie auf eine Webseite des Servers gehen, der persistente Cookie gespeichert wird identifiziert Sie, damit Sie sich nicht erneut anmelden müssen. Hier speichert der Cookie genügend Informationen - oft in einer verschlüsselten Form, die nur der Server verstehen kann - um Sie zu identifizieren. In diesem Fall ist das Cookie keine einfache Sitzungs-ID.
Sehr einfach erklärt, was passiert, wird unten erwähnt:
Es gibt im Wesentlichen zwei Möglichkeiten, die Authentifizierung im Internet durchzuführen, und einige weniger beliebte Möglichkeiten, die es auch wert sind, darüber informiert zu werden.
Der erste Schritt ist die HTTP-Authentifizierung gemäß RFC 2617 . Wenn Sie eine geschützte Seite anfordern, antwortet der Server mit einem 401 Statuscode und signalisiert, dass Sie nicht auf die Ressource zugreifen dürfen. Außerdem sendet es einen WWW-Authenticate -Header, der den Browser anweist, wie er sich autorisieren soll. Der Browser sieht diesen Statuscode und die Kopfzeile und fordert Sie zur Eingabe Ihrer Authentifizierungsdetails auf. Wenn Sie sie eingeben, bereitet Ihr Browser sie entsprechend dem vom Server angegebenen Authentifizierungsschema vor und fordert die Seite erneut an, einschließlich eines Headers Authorization mit den vorbereiteten Details. Der Server prüft diese Details anhand seiner Benutzerdatenbank und antwortet entweder mit einem anderen 401 (falsche Details) oder der geschützten Seite mit einem begleitenden 200 Statuscode, um den Erfolg anzuzeigen.
Die HTTP-Authentifizierung ist eine dieser uralten Funktionen, die von Browsern zunächst nicht gut implementiert und nie wirklich verbessert wurden. Aus diesem Grund ist es für Webentwickler sehr viel populärer geworden, die Authentifizierung selbst zu implementieren, indem Cookies verwendet werden, um den Status beizubehalten. In diesem Fall wird dem Benutzer ein Standard-HTML-Formular präsentiert. Wenn der Benutzer seine Anmeldeinformationen in die Felder eingibt und das Formular absendet, codiert der Browser es und sendet es an den Server auf die gleiche Weise, wie es ein normales HTML-Formular codiert. Der Server überprüft die Anmeldeinformationen und legt bei Legitimität ein Cookie mit einer zufällig generierten ID-Nummer sowie einem entsprechenden Datenbank- / Dateisystemeintrag fest, der diese ID-Nummer als zu einem bestimmten Benutzer gehörend erkennt.
Ab diesem Zeitpunkt enthält jede Anfrage, die der Browser an den Server stellt, dieses Cookie mit der ID-Nummer als HTTP-Header. Der Server erkennt den Cookie, sucht die ID-Nummer und weiß, welcher Benutzer Sie sind. Wenn Sie sich abmelden, sendet der Server eine Antwort, in der Sie aufgefordert werden, die ID-Nummer zu vergessen. An diesem Punkt sind Sie nur ein weiterer anonymer Benutzer.
Eine weniger gebräuchliche Option ist die Verwendung von SSL-Client-Zertifikaten. Viele Menschen sind mit der Idee vertraut, SSL zum Identifizieren eines Servers zu verwenden. Ein kryptografisches Schlüsselpaar wird generiert, von einer vertrauenswürdigen Autorität signiert und verwendet, um zu beweisen, dass die gesendeten Daten vom Besitzer des Schlüsselpaares stammen. Was viele Leute nicht wissen, ist, dass dasselbe auch von einem Client verwendet werden kann, um seine Identität gegenüber einem Server nachzuweisen. Dies ist jedoch weniger praktisch, da Sie Ihr Zertifikat mit sich herumtragen müssen, wenn Sie es auf mehreren Computern verwenden möchten.
Natürlich gibt es Variationen und weniger bekannte Optionen, aber diese sind die bekanntesten.
Wie andere bereits erwähnt haben, variieren die Anmeldeverfahren je nach Implementierung, aber der grundlegende Fall (einfache Web-App-Authentifizierung) verwendet ungefähr den folgenden Pseudocode:
%Vor%Natürlich wird es in den meisten Fällen etwas komplizierter, aber jede Login-Funktion beginnt ihr Leben im Wesentlichen wie oben beschrieben. Jetzt, wenn wir dem Mix automatisches Login hinzufügen ("erinnere mich an mich"), erhalten wir so etwas:
%Vor%Zusätzlich die Funktion zur automatischen Anmeldung, wenn ein Cookie vorhanden ist:
%Vor%HINWEIS: Der obige Ansatz ist kein Ansatz der "besten Vorgehensweise" und nicht sehr sicher. Im Produktionscode würden Sie immer eine Benutzerkennung in die Cookie-Daten aufnehmen, mehrere Drosselungsebenen verwenden, Daten über fehlgeschlagene und erfolgreiche Logins speichern usw. All dies wurde entfernt, um die grundlegende Struktur der Authentifizierung einfacher zu machen.
Wie auch immer, ich hoffe, das ist das, wonach du gesucht hast, koldfyre. Ich kenne Ihren Hintergrund nicht, aber wenn Sie nicht sicher sind, wie Sitzungen und Cookies funktionieren, sollten Sie sie separat lesen, und wenn Sie ausführlichere Details benötigen, fragen Sie einfach.
PS: Vielleicht möchten Sie auch die Frage " Der endgültige Leitfaden zur Website-Authentifizierung " für die beste Vorgehensweise überprüfen Ansätze
Sehen Sie, es ist ein wenig schwierig, Ihnen viel mehr Informationen zu geben, die Sie bereits hier haben; Ich bin nicht sicher, warum Sie ein Kopfgeld darauf setzen wollen. Ein Cookie ist nur ein kleines bisschen von benannter Information, und Sie können alles, was Sie mögen, hineinlegen. Für eine Sitzung möchten Sie eine einige Art der Sitzungs-ID haben. Dafür gibt es Konventionen, oder Sie können es selbst tun. Was auch immer Sie tun, wenn Sie den Cookie setzen, hinterlassen Sie ein paar Daten über den Browser der Person, die mehr oder weniger wie folgt aussehen:
%Vor%Wenn Sie zurückkommen, holen Sie den Keks zurück und holen ihn zurück.
Wenn Sie alle Einzelheiten dieses Protokolls sehen möchten, sehen Sie sich den Wikipedia-Artikel an.
>Tags und Links authentication login