Ich habe eine Standard-HTML-Anmeldeseite, die ich lieber verwenden würde als das standardmäßige HTTP-Authentifizierungs-Popup, das von Browsern bereitgestellt wird. Heute benutze ich Session-Cookies, um die Sitzung nach der Anmeldung zu verfolgen, aber ich würde gerne statusfrei sein und die HTTP-Authentifizierung jedes Mal weitergeben. Die Webdienste, die ich treffe, unterstützen dies bereits, daher handelt es sich um ein reines Browserproblem.
Das Hinzufügen von Authentifizierungsdaten ist in jQuery trivial, aber ich weiß nicht, wie ich sie behalten soll. Wenn Sie von der Login-Seite (ein JSP) auf die Home-Seite (ein anderes JSP) gehen, behalten Sie eindeutig nicht die Felder Benutzername und Passwort von der Login-Seite. Ich weiß, einige Browser werden Ihre HTTP-Authentifizierungsdaten speichern, wenn Sie sie aus dem Popup eingeben, aber ich weiß nicht, ob sie bei der Verwendung eines XHRRequest gespeichert werden. Wenn ja, besteht zwischen den Browsern eine große Übereinstimmung?
Auch muss der Benutzer in der Lage sein, sich von der Anwendung "abzumelden". Wenn der Browser die Authentifizierungsdaten speichert, können Sie diese mit JavaScript löschen.
Ich glaube, ich kann nicht die erste Person sein, die versucht, dies zu lösen. Gibt es ein jQuery-Plugin oder etwas, das das bereits erledigt? Oder ist es einfach nicht möglich zu tun, was ich versuche?
Die folgende Antwort wurde 2012 veröffentlicht und die Links sind größtenteils tot. Seither wurde jedoch ein eleganterer standardbasierter Ansatz für die gleiche Lösung unter Verwendung von JSON-Web-Token entwickelt. Hier ist ein guter Blogbeitrag , der erklärt, wie man sie benutzt.
Die meisten Antworten vermissen den Punkt, nämlich eine serverseitige Sitzung zu vermeiden. Ich möchte keinen Anwendungsstatus auf dem Server. Ich werde das Kopfgeld vergeben, um die Antwort zu geben, die am nächsten kommt, aber der wahre Verdienst geht an die Rest-Diskussion-Gruppe und Jon Moore für die richtige Antwort und Mike Amundsen um mir zu helfen, es wirklich zu verstehen.
Die beste Antwort, die ich bekommen habe, ist die Verwendung eines Cookies, aber nicht das typische automatische Session-ID-Cookie, das Ihnen von den meisten Anwendungsservern gegeben wird. Der Cookie (der automatisch mit jeder nachfolgenden Anfrage gesendet wird) ist eine Benutzerkennung und eine vom Server signierte Zeit. Sie können eine Ablaufzeit mit dem Cookie einschließen, so dass die typische 30-Minuten-Sitzung auf einem Server simuliert wird (was bedeutet, dass Sie sie mit nachfolgenden Anfragen weiterleiten müssen) und das gleiche Cookie für immer gültig bleibt.
Der XHR / AJAX-Teil ist ein Ablenkungsmanöver. Dies funktioniert, unabhängig davon, ob Sie XHR-Anfragen oder eine altmodische Seite-für-Seite-Webanwendung ausführen. Die wichtigsten Punkte sind:
Sie haben 2 Optionen:
1) Clientseitige Speicherung von Anmeldeinformationen - keine gute Idee. Aus offensichtlichen Gründen möchten Sie den Benutzernamen / das Passwort nicht auf dem Client speichern. Wenn Sie eine Hash-Version des Passworts haben, ist es möglicherweise nicht so schlecht, aber immer noch nicht zu empfehlen. In jedem Fall müssen Sie, wenn Sie auf der Client-Seite speichern, entweder ein Cookie verwenden oder Lokaler HTML5-Speicher (der noch nicht allgemein unterstützt wird)
2) Serverseitige Speicherung von Anmeldeinformationen - typischerweise mit Sitzungen. Anschließend kann die resultierende Sitzungs-ID an den Client zurückgegeben und entweder in einem Cookie oder in der URL jedes nachfolgenden AJAX-Aufrufs ( ?SESSID=xyz zum Beispiel) gespeichert werden
Der serverseitige Ansatz wäre der sicherste, zuverlässigste und am einfachsten zu implementierende
Okay, ich werde einen Stoß geben, um zu helfen ...
Verstehen Sie zunächst, wie die HTTP-Authentifizierung funktioniert. Es gibt zwei Versionen - Basic und Digest. Basic überträgt im Klartext, Digest ist verschlüsselt. Bei diesen Arten der Authentifizierung wird der Benutzername / das Passwort bei jeder Anfrage im HTTP-Header übergeben. Der Browser erfasst diese bei der Anmeldung und sie werden in einem nicht zugänglichen Browser-Sitzungscookie gespeichert, der gelöscht wird, wenn die Browsersitzung geschlossen wird. Also, als Antwort auf eine Ihrer Fragen, können Sie nicht auf diese von Javascript zugreifen.
Sie können Ihre eigenen Session-Cookie-Variablen für Benutzername und Passwort erstellen. Die jQuery-Funktionen dafür sind wirklich einfach. Ein Beispiel zum Festlegen von Sitzungscookies finden Sie im Modul jquery-cookie . Diese könnten aus dem Session-Cookie abgerufen und mit jeder Ajax-Anfrage gesendet und auf dem Server validiert werden. Dies ist jedoch keine besonders gute Möglichkeit, eine Authentifizierung durchzuführen, da das Sniffing des Netzwerks es jedem ermöglicht, einfach Ihre Authentifizierungsdetails zu erfassen. Aber es würde funktionieren.
Die Verwendung der Session-Cookie-basierten Authentifizierung, bei der die Sitzungs-ID gesendet wird, ist bei jeder Anfrage der beste Weg, dies zu tun. Auf der Serverseite muss für jede HTTP-Anforderung eine Funktion aufgerufen werden. Diese Funktion sollte Folgendes tun:
%Vor%Die meisten Web-Frameworks unterstützen die Session-Cookie-Authentifizierung und die Verwaltung von Sitzungs-IDs auf dem Server. Dies ist definitiv der richtige Weg.
Das ist interessant.
Verwalten Sie Benutzersitzungen auf dem Server mithilfe von Cookies. Erstellen Sie eine Sitzung, wenn der Benutzer zuerst auf die Anmeldeseite zugreift und die Sitzungs-ID / den Schlüssel als Wert an einen der Cookies über die Antwort weitergibt. Wenn der Benutzer authentifiziert wird, legen Sie die Benutzerschlüsselinformationen in den Cookie und die Werte im Anwendungskontext auf dem Server ab. Sobald der Benutzer angemeldet ist, wird jede nachfolgende Anfrage basierend auf dem Sitzungscookie-Wert auf dem Server authentifiziert. Die Autorisierung erfolgt auf der Basis des Benutzerschlüssels, der als Cookie-Wert übergeben wurde.
Beim Abmelden löschen Sie die sitzungsbasierten Cookies vom Server und aktualisieren Sie die Site auf die Standardseite.
Cookies sind bizarr mit verschiedenen Browsern - nur eine Anmerkung;)
Hoffe, das hilft.
Etwas interessant darin, dass Sie daran denken, etwas von der Authentizität an den Kunden zu übertragen. Wenn Sie eine konventionelle Lösung wünschen, ist der serverseitige Vorschlag von KOGI der richtige Weg.
Aber Sie scheinen auch Fragen über Speicherlecks zu stellen, die Ihre vom Benutzer gelieferten Geheimnisse betreffen. Gute Fragen. Aber um eine allgemeine Stichelei zu beantworten, würde ich sagen, dass es browserspezifisch sein müsste. Es ist browser internals, javascript engine internals-abhängig, wo eine clientseitige Anwendung (d. H. Der Browser oder js im Browser) die Werte speichert, die der Benutzer eingibt.
Wahrscheinlich werden diese Werte nicht unnötig im gesamten Speicher repliziert, aber es gibt keine Möglichkeit, dies zu garantieren. Abgesehen von verantwortungsvollen JavaScript-Codierungsverfahren gibt es nichts, was Sie tun können, um das Limit der Speicherorte von Benutzereingaben zu garantieren.
Geringfügiger Exkurs
Der grundlegende Punkt ist, wenn Sie es auf dem Client speichern, ist es nicht wirklich sicher - es sei denn, der Server speichert verschlüsselte Informationen auf dem Client mit einem Schlüssel, den nur der Server (oder der Benutzer über ihre korrekten Zugangsdaten) hat. Sie könnten also eine JS-Anwendung so programmieren, dass sie auf dem Client authentifiziert wird - ähnlich wie eine Bankkarte (früher?) Eine POS-Authentifizierung durchführt, indem sie die PIN der PIN auf der Karte und nicht die DB überprüft. Es basiert auf der (etwas fadenscheinigen) Annahme, dass der Benutzer keinen direkten Lese- / Schreibzugriff auf den "dunklen Bereich" -Cookie / lokalen Speicher auf dem Client / Mag-Streifen auf der Bankkarte hat. Daher würde ich dies nur als Disqualifier für falsche Authents und nicht als alleinigen Qualifier für die Credentials empfehlen.
Hauptpunkt
Wenn Sie statusfrei sein möchten, speichern Sie die Benutzeranmeldeinformationen einfach im lokalen Speicher oder als Cookie, verschlüsseln Sie sie jedoch mit einem Serverschlüssel. Wenn Sie ein XHR mit den verschlüsselten / gespeicherten Anmeldeinformationen über HTTPS an den Server senden möchten, lassen Sie Ihren Server diese entschlüsseln und an den Rückruf senden. Übergeben Sie dann diesen Klartext von HTTPS, um Ihr Authent zu machen.
Tags und Links jquery ajax xmlhttprequest http-authentication stateless-session