Zammad: HTTP 401-Antworten verursachen Probleme mit der Standardauthentifizierung

Bitte aktualisieren Sie Ihren ersten Artikel, um Ihre genauen Installationsinformationen zu erhalten - "any" ist derzeit nicht wirklich geeignet - sorry. :) :)

Bitte geben Sie auch Ihre vollständige Webserver-Konfiguration an (und teilen Sie uns mit, welche Sie verwenden). Im Moment riecht es ein bisschen nach einer technischen Frage, aber ich würde es gerne ganz sicher stellen. Dafür brauche ich aber alles. ;)

Vielen Dank.

Hallo nochmal,
Ich habe die Problembeschreibung aktualisiert - entschuldigen Sie das anfängliche Fehlen!
Beste

Danke für das Update. Die Konfiguration Ihres Webservers ist unsere Standardkonfiguration, die um die Basisauthentifizierung erweitert wurde. Würde es Ihnen etwas ausmachen, auch diese vhost-Konfiguration bereitzustellen? Nur um sicherzugehen, dass mir nichts fehlt.

Vielen Dank!

Ja, es ist im Grunde nur Zammad Standardkonfiguration + Basic Auth. Hier ist die vhost-Konfiguration:

auth_basic 'Restricted: general basic auth';
auth_basic_user_file /etc/.htpasswd.d/zammad;
location /ws {
    proxy_pass  http://zammad_ws;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  443;
    proxy_set_header CLIENT_IP $remote_addr;
    proxy_read_timeout 86400;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    error_page 502 503 504 =503 @fallback;
}
location / { 
    try_files $uri @proxy;
}
location <strong i="6">@proxy</strong> { 
    proxy_pass  http://zammad;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto https;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  $server_port;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    proxy_set_header CLIENT_IP $remote_addr;
    error_page 502 503 504 =503 @fallback;
}

Wir haben uns das noch einmal angesehen.
Unsere Vermutung (wie Michael schrieb) wäre, kein HTTP 401 zurückzugeben (was den Browser glauben lässt, dass die angegebenen grundlegenden Authentifizierungsdaten falsch sind), sondern HTTP 403 verboten zurückzugeben.

Wenn ich es richtig sehen würde, würde das bedeuten

app / controller / application_controller / handle_errors.rb # L39
respond_to_exception(e, :unauthorized)

sollte durch ersetzt werden
respond_to_exception(e, :forbidden)

Laut RFC sollten sich Browser anders verhalten (https://tools.ietf.org/html/rfc7231#section-6.5.3): "Wenn in der Anforderung Authentifizierungsdaten angegeben wurden, hält der Server sie für unzureichend, um Zugriff zu gewähren. Der Client SOLLTE Wiederholen Sie die Anforderung NICHT automatisch mit denselben Anmeldeinformationen. "

Allerdings hatten wir letzte Woche das gleiche Problem in einem anderen Projekt und 403 Arbeiten.
Wenn Sie keine anderen Probleme bei der Rückgabe eines 403 sehen, können wir eine PR ausstellen.

Beste

Tut mir leid, dass ich so lange gebraucht habe.
Bitte beachten Sie, dass dies kein Zammad-Problem (anwendungsbasiert) ist, sondern ein "Backend-Problem" auf Ihrem Nginx.

Die Authentifizierungsanforderungen für die Basisauthentifizierung erreichen Zammad nie als Anwendung, beenden jedoch bereits Ihren Nginx oder einen anderen von Ihnen verwendeten Webserver (und werden von diesem überprüft).

Daher ist das Ändern des Quellcodes meiner Meinung nach überhaupt keine Lösung für Ihr Problem.
Technisch gesehen ist ein 401, der nicht autorisiert ist, korrekt, soweit ich das beurteilen kann (obwohl ich verstehe, dass Sie einen 403 wollen).

Siehe auch:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

Apropos:
Zur Überprüfung habe ich die Zammad-Proxy-Teile vollständig auskommentiert, um sicherzustellen, dass das Backend von Zammad nicht antworten kann. Das Ergebnis mit 401 ist das gleiche und somit ein Fehler von Nginx. :) :)

Das Schließen ist kein Fehler, sondern eine technische Frage.

Hallo @ MrGeneration ,
Vielen Dank, dass Sie sich damit befasst haben.

Obwohl ich verstehe, dass dieses Problem für die Zammad-Anwendung möglicherweise nicht in den Anwendungsbereich fällt, denke ich dennoch, dass es dadurch verursacht wird (und nicht durch Ngnix). Ich werde versuchen zu erklären warum:

Nehmen wir an, unser ngnix ist nicht für die Verwendung der Basisauthentifizierung konfiguriert. In diesem Fall sind wir uns beide einig, dass die Zammad-Anwendung ("hinter" dem ngnix) einwandfrei funktioniert.

Jetzt aktivieren wir die Basisauthentifizierung, indem wir die oben angegebene Konfiguration zu unserem ngnix hinzufügen. Bitte beachten Sie, dass auch jetzt noch fast alles wie erwartet funktioniert - einschließlich der Authentifizierungen (Basis- und Zammad-Login) und der Zammad-Anwendung selbst.

Das Problem, das ich zuvor zu beschreiben versucht habe, wird manchmal später (von Zammad!) Verursacht, wenn die Anwendung eine Seite mit dem Statuscode 401 rendert. In diesem Fall muss sich jeder Webserver mit aktivierter Basisauthentifizierung abmelden.

Ich stimme zu, dass semantisch 401 in diesem Fall "genau richtig" klingt. Technisch gesehen verursacht es unvermeidliche Probleme mit der Basisauthentifizierung und sollte durch 403 ersetzt werden.
Öffnen Sie dieses Problem erneut, da es für viele Benutzer auch Auswirkungen auf die Benutzeroberfläche der Zammad-Anwendung haben kann.

@thorsteneckel was ist deine

Hallo Leute! Vielen Dank für die wertvollen Informationen und Beschreibungen. Ich habe den RFC gelesen und war immer noch etwas verwirrt über die Unterschiede zwischen 401 und 403. Diese großartige Erklärung fand ich jedoch bei StackOverflow. Zitat:

Es gibt ein Problem mit 401 Unauthorized, dem HTTP-Statuscode für Authentifizierungsfehler. Und das war's auch schon: Es dient der Authentifizierung, nicht der Autorisierung.

Das bringt es auf den Punkt. Zammad verwendet 401 für authorization Fehler. Dies ist technisch falsch und daher ein Fehler. Ich werde das Problem erneut öffnen.

Wir müssen jedoch die Auswirkungen überprüfen. Ich gehe davon aus, dass dies aufgrund all der Implementierungen und API-Konsumenten eine bahnbrechende Änderung ist.
Mein aktueller Plan ist es, 401 authorization mit Zammad 3.4 sanft zu verwerfen, es mit 3.5 (oder 3.6) hart zu verwerfen und zu 403 zu wechseln.
Wir müssen dies intern weiter diskutieren.

Weitere Gedanken dazu jemand?

Das sind großartige Neuigkeiten! Klingt gut für mich.

Um Sie auf dem Laufenden zu halten: Wir werden dies mit der kommenden Version 4.0 implementieren.

Für interne Implementierungszwecke: https://thoughtbot.com/blog/forbidden-kisses-http-fluency-in-clearance

Mit dem obigen Commit behoben. Wir haben die Chance genutzt und einige der Meldungen über 401 Fehler verbessert, aber im Grunde haben wir nur die Nicht-Authentifizierungsfehler in 403 Forbidden geändert.

Sie können dies in etwa 30 Minuten mit dem neuesten develop -Paket testen. Bitte beachten Sie, dass dies ein funktionierender Zweig ist und nicht stabil. Stellen Sie daher sicher, dass Sie ein Backup haben und das Schlimmste erwarten :) Wir freuen uns auf Ihr Feedback!