Frage

Meine Web-Anwendung verfügt über eine Login-Seite, die Authentifizierungsinformationen über einen AJAX-Aufruf übergibt. Wenn der Benutzer den richtigen Benutzernamen und ein Passwort eingibt, alles ist in Ordnung, aber wenn nicht, geschieht Folgendes:

  1. Der Web-Server feststellt, dass, obwohl die Anforderung einen wohlgeformten Authorization-Header enthalten ist, können die Anmeldeinformationen im Header nicht erfolgreich authentifiziert werden.
  2. Der Web-Server gibt einen Statuscode 401 und umfasst eine oder mehrere WWW-Authenticate-Header der unterstützten Authentifizierungstypen auflistet.
  3. erkennt der Browser, dass die Antwort auf meinen Anruf auf dem XMLHttpRequest-Objekt ist ein 401 und die Antwort enthält WWW-Authenticate-Header. Es erscheint dann eine Authentifizierungs-Dialog fragen nach oben, wieder für den Benutzernamen und das Passwort.

Das ist alles in Ordnung, bis Schritt 3 Ich will nicht der Dialog Pop-up, ich mag, will die 401-Antwort in meiner AJAX Callback-Funktion behandeln. (Zum Beispiel durch eine Fehlermeldung auf der Login-Seite angezeigt werden.) Ich möchte der Benutzer seinen Benutzernamen und Passwort erneut eingeben, natürlich, aber ich möchte, dass sie meine freundlich, beruhigend Login-Formular sehen, nicht die hässlichen des Browsers Standard Authentifizierungsdialog.

Übrigens habe ich keine Kontrolle über den Server haben, so haben sie einen benutzerdefinierten Statuscode zurückgeben (das heißt, etwas anderes als eine 401) ist keine Option.

Gibt es eine Möglichkeit, den Authentifizierungsdialog unterdrücken kann? Insbesondere kann ich die Authentifizierung erforderlich Dialog in Firefox 2 oder höher unterdrücken? Gibt es eine Möglichkeit, die Verbindung zu [host] Dialog in IE 6 und höher?

zu unterdrücken

Bearbeiten
Weitere Informationen des Autors (18. September):
Ich soll hinzufügen, dass das eigentliche Problem mit dem Authentifizierungsdialog Aufspringen des Browsers ist, dass es nicht genügend Informationen für den Benutzer geben.

Der Benutzer hat nur einen Benutzername und Passwort über das Formular auf der Login-Seite eingegeben, er glaubt, dass er sich richtig eingegeben hat beide, und er hat die Absenden-Button geklickt oder drücken Sie die Eingabetaste. Seine Erwartung ist, dass er auf die nächste Seite genommen wird, oder vielleicht gesagt, dass er seine Informationen falsch eingegeben und soll erneut versuchen. Aber er wird stattdessen mit einem unerwarteten Dialogfeld angezeigt.

Der Dialog macht keine Anerkennung der Tatsache, dass er nur hat einen Benutzernamen und ein Passwort eingeben. Es ist nicht klar zu sagen, dass es ein Problem war und dass er erneut versuchen. Stattdessen stellt das Dialogfeld die Benutzer mit kryptischen Informationen wie „Die Seite sagt:‚ [Bereich] .‘“ Wo [Bereich] ist ein kurzer Bereichsnamen, die nur ein Programmierer lieben könnte.

Web broswer Designer zur Kenntnis nehmen: niemand würde fragen, wie der Authentifizierungsdialog zu unterdrücken, wenn der Dialog selbst einfach benutzerfreundlicher war. Das gesamte Grund, dass ich ein Login-Formular tue, ist, dass unser Produktmanagement-Team zu Recht der Authentifizierungs-Dialoge Browser betrachtet schrecklich zu sein.

War es hilfreich?

Lösung

Ich glaube nicht, das ist möglich - wenn Sie den Browser des HTTP-Client-Implementierung verwenden, wird es immer diesen Dialog eingeblendet. Zwei Hacks in den Sinn kommen:

  1. Vielleicht Flash-Griffe dies anders (ich habe noch nicht ausprobiert), so dass ein Flash-Film die Anforderung helfen könnte machen zu müssen.

  2. Sie können eine ‚Proxie‘ für den Dienst einrichten, die Sie auf Ihrem eigenen Server zuzugreifst, und haben sie den Authentifizierungs-Header ein wenig ändern, so dass der Browser nicht erkennen.

Andere Tipps

begegnete ich das gleiche Problem hier, und der Back-End-Ingenieur in meinem Unternehmen implementiert ein Verhalten, das anscheinend eine gute Praxis gilt: wenn ein Aufruf eine URL gibt ein 401, wenn der Kunde den Header X-Requested-With: XMLHttpRequest gesetzt hat, der Server-Tropfen die www-authenticate Header in seiner Antwort.

Der Nebeneffekt ist, dass der Standard-Authentifizierungs Popup nicht angezeigt.

Stellen Sie sicher, dass Ihre API-Aufruf die X-Requested-With Header hat auf XMLHttpRequest. Wenn dies der Fall ist, gibt es nichts, außer daß das Serververhalten zu tun, nach dieser guten Praxis ...

Der Browser öffnet sich ein Login-Prompt auf, wenn die beiden folgenden Bedingungen erfüllt sind:

  1. HTTP-Status ist 4xx
  2. WWW-Authenticate Header ist in der Antwort

Wenn Sie die HTTP-Antwort kontrollieren können, dann können Sie den WWW-Authenticate Header aus der Antwort entfernen, und der Browser den Anmeldedialog Popup.

Wenn Sie die Antwort nicht kontrollieren können, können Sie das Einrichten eines Proxy die WWW-Authenticate Header aus der Antwort herausgefiltert werden.

Soweit ich weiß (fühlen Sie sich frei, mich zu korrigieren, wenn ich falsch), gibt es keine Möglichkeit, die Anmeldeaufforderung zu verhindern, sobald der Browser den WWW-Authenticate Header empfängt.

Ich weiß, dass diese Frage und ihre Antworten sehr alt sind. Aber ich hier gelandet. Vielleicht andere werden als gut.

Wenn Sie Zugriff auf den Code für den Web-Dienst, der die 401. einfach zurückkehren den Dienst ändern, um einen 403 (Forbidden) in dieser Situation statt 401. Den Browser aufgefordert, nicht zu einem 403 für Anmeldeinformationen als Antwort zurück. 403 ist der richtige Code für einen authentifizierten Benutzer, die nicht für eine bestimmte Ressource autorisiert ist. Welche scheint sich die Lage des OP zu sein.

Von dem IETF-Dokument auf 403:

Ein Server, die gültigen Anmeldeinformationen erhält, die nicht ausreichend ist, um    erhält Zugang sollte mit dem 403 (Verboten) Statuscode

reagieren

Mozilla Sie es mit dem folgenden Skript erreichen können, wenn Sie das XMLHttpRequest-Objekt zu erstellen:

xmlHttp=new XMLHttpRequest();
xmlHttp.mozBackgroundRequest = true;
xmlHttp.open("GET",URL,true,USERNAME,PASSWORD);
xmlHttp.send(null);

Die zweite Zeile verhindert, dass das Dialogfeld ....

Welche Server-Technologie verwenden Sie, und ist es ein bestimmtes Produkt für die Authentifizierung verwenden?

Da der Browser nur seine Arbeit tun, ich glaube, Sie haben die Dinge auf der Serverseite zu ändern, um einen 401-Statuscode nicht zurück. Dies könnte unter Verwendung von benutzerdefinierten Authentifizierungsformen erfolgen, die einfach das Formular wieder zurück, wenn die Authentifizierung fehlschlägt.

Mozilla Land, das mozBackgroundRequest Parameter von XMLHttpRequest-Einstellung ( docs ) auf true unterdrückt diese Dialoge und bewirkt, dass die Anfragen einfach zum scheitern verurteilt. Aber ich weiß nicht, wie gut Cross-Browser-Unterstützung (einschließlich, ob die Qualität der Fehlers Informationen über diese fehlgeschlagenen Anfragen in allen Browsern sehr gut.)

jan.vdbergh die Wahrheit hat, wenn Sie die 401 auf Server-Seite für einen anderen Statuscode ändern kann, wird nicht der Browser fangen und das Pop-up malen. Eine andere Lösung könnte die WWW-Authenticate-Header für einen anderen benutzerdefinierten Header sein ändern. Ich dont't glauben, warum die anderen Browser es nicht, in einigen Versionen von Firefox unterstützen, können wir die xhr Anfrage mit mozBackgroundRequest tun können, aber in den anderen Browsern ?? hier gibt es eine interessante link mit diesem Thema in Chrom.

Ich habe das gleiche Problem mit MVC 5 und VPN, wo, wenn wir außerhalb der DMZ mit dem VPN sind, finden wir uns diese Browser-Nachricht zu beantworten haben. Mit .net ich einfach das Routing des Fehlers behandeln mit

<customErrors defaultRedirect="~/Error"  >
  <error statusCode="401" redirect="~/Index"/>
</customErrors>

bisher hat es funktioniert, weil die Index Aktion im Rahmen der Heimsteuerung der Benutzer überprüft. Die Aussicht auf dieser Aktion, wenn die Anmeldung nicht erfolgreich ist, hat Login-Steuerelemente, die ich verwende, um die Benutzer bei der Verwendung mit LDAP-Abfrage in Verzeichnisdienste weitergegeben zu protokollieren:

      DirectoryEntry entry = new DirectoryEntry("LDAP://OurDomain");
      DirectorySearcher Dsearch = new DirectorySearcher(entry);
      Dsearch.Filter = "(SAMAccountName=" + UserID + ")";
      Dsearch.PropertiesToLoad.Add("cn");

Während dies bisher gut funktioniert hat, und ich muß Ihnen mitteilen, dass ich es immer noch am Testen und der obige Code hat keinen Grund hat zu laufen, so ist es unter Entfernung ... zur Zeit Getestet werden versuchen, einen Fall zu entdecken, wo der zweite Satz von Code ist von nicht mehr verwenden. Auch dies ist ein work in progress, aber da es von einem gewissen Nutzen sein könnte oder Ihr Gehirn für einige Ideen joggen, habe ich beschlossen, es jetzt hinzuzufügen ... Ich kann es mit den endgültigen Ergebnissen, wenn alle Tests durchgeführt werden aktualisiert.

Für diejenigen unsing C # hier ActionAttribute die 400 statt 401 zurückgibt, und 'schluckt' Grund Auth-Dialog.

public class NoBasicAuthDialogAuthorizeAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
    {
        base.HandleUnauthorizedRequest(filterContext);
        filterContext.Result = new HttpStatusCodeResult(400);
    }
}

Verwendung wie folgt:

[NoBasicAuthDialogAuthorize(Roles = "A-Team")]
public ActionResult CarType()
{
 // your code goes here
}

Hope dies spart Ihnen einige Zeit.

Ich bin mit Knoten, Express & Passport und wurde mit dem gleichen Problem zu kämpfen. Ich habe es durch explizites Setzen des www-authenticate Header auf einen leeren String zu arbeiten. In meinem Fall sah es wie folgt aus:

(err, req, res, next) => {
  if (err) {
    res._headers['www-authenticate'] = ''
    return res.json(err)
  }
}

Ich hoffe, das hilft jemand!

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top