Zammad: Réponses HTTP 401 provoquant des problèmes avec l'authentification de base

Veuillez mettre à jour votre premier article pour conserver vos informations d'installation exactes - "any" ne convient pas vraiment à ce stade - désolé. :)

Veuillez également fournir la configuration complète de votre serveur Web (et nous indiquer celui que vous utilisez). En ce moment, ça sent un peu comme une question technique, mais j'aimerais m'en assurer complètement. Cependant, pour cela, j'ai besoin de tout. ;)

Merci.

Re-bonjour,
J'ai mis à jour la description du problème - désolé pour le manque initial!
Meilleur

Merci pour la mise à jour. La configuration de votre serveur Web est-elle notre configuration par défaut étendue par l'authentification de base? Pourriez-vous également fournir cette configuration vhost? Juste pour être sûr de ne rien manquer.

Merci!

Oui, il s'agit essentiellement de la configuration Zammad Default + Basic Auth. Voici la configuration de vhost:

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;
}

Nous avons examiné cela à nouveau.
Notre hypothèse (comme Michael l'a écrit) serait de ne pas renvoyer un HTTP 401 (ce qui fait croire au navigateur que les informations d'authentification de base données sont incorrectes) mais de renvoyer HTTP 403 interdit.

Si je le voyais correctement, cela signifierait

app / controllers / application_controller / handles_errors.rb # L39
respond_to_exception(e, :unauthorized)

doit être remplacé par
respond_to_exception(e, :forbidden)

La RFC indique que les navigateurs doivent se comporter différemment (https://tools.ietf.org/html/rfc7231#section-6.5.3): "Si les informations d'authentification ont été fournies dans la demande, le serveur les considère insuffisantes pour accorder l'accès. Le client DEVRAIT NE PAS répéter automatiquement la demande avec les mêmes informations d'identification. "

Cependant, nous avons eu le même problème dans un autre projet la semaine dernière et 403 œuvres.
Si vous ne voyez pas d'autres problèmes pour renvoyer un 403, nous pouvons émettre un PR.

Meilleur

Désolé d'avoir été si long.
Veuillez noter que ce n'est pas un problème lié à Zammad (basé sur une application), mais un "problème de backend" sur votre nginx.

Les demandes d'authentification pour l'authentification de base n'atteignent jamais Zammad en tant qu'application mais se terminent déjà (et sont vérifiées par) votre nginx ou tout autre serveur Web que vous utiliseriez.

Ainsi, changer le code source ne résout pas du tout votre problème.
Techniquement, un 401 non autorisé est correct d'après ce que je peux dire (même si je comprends que vous voudriez un 403).

Voir également:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

D'ailleurs:
Juste pour vérifier, j'ai complètement commenté les parties du proxy Zammad pour m'assurer que le backend de Zammad ne peut pas répondre. Le résultat avec 401 est le même et donc la faute de nginx. :)

Clôture car ce n'est pas un bug mais une question technique.

Salut @MrGeneration ,
merci d'avoir examiné cela.

Bien que je comprenne que ce problème semble être hors de portée pour l'application Zammad, je pense toujours qu'il est causé par elle (et non par le Ngnix). Je vais essayer d'expliquer pourquoi:

Supposons que notre ngnix n'est pas configuré pour utiliser l'authentification de base. Dans ce cas, nous convenons tous les deux que l'application Zammad ("derrière" le ngnix) fonctionne très bien.

Maintenant, nous activons l'authentification de base en ajoutant la configuration indiquée ci-dessus à notre ngnix. Veuillez noter que même maintenant, presque tout fonctionne toujours comme prévu - y compris les authentifications (connexion de base et Zammad) et l'application Zammad elle-même.

Le problème que j'ai essayé de décrire plus tôt est parfois causé plus tard (par Zammad!) Lorsque l'application affiche une page avec le code d'état 401. Dans ce cas, _tout serveur Web_ avec l'authentification de base activée est obligé de vous déconnecter.

Je conviens que, sémantiquement parlant, 401 sonne «juste» dans ce cas. Techniquement parlant, cela pose des problèmes inévitables avec l'authentification de base et devrait être remplacé par 403.
Veuillez rouvrir ce problème car il peut également affecter l'UX de l'application Zammad pour de nombreux utilisateurs.

@thorsteneckel quelle est votre opinion à ce sujet?

Salut les gars! Merci pour les précieuses informations et descriptions. J'ai lu la RFC et j'étais encore un peu confus sur les différences entre 401 et 403. Cependant, j'ai trouvé cette excellente explication sur StackOverflow. Citation:

Il y a un problème avec 401 Unauthorized, le code d'état HTTP pour les erreurs d'authentification. Et c'est juste cela: c'est pour l'authentification, pas pour l'autorisation.

Cela l'amène au fait. Zammad utilise 401 pour les erreurs authorization . Ceci est techniquement faux et donc un bug. Je rouvrirai le numéro.

Cependant, nous devons vérifier l'impact. Je suppose qu'il s'agit d'un changement radical en raison de toutes les implémentations et des consommateurs d'API disponibles.
Mon plan actuel est de déprécier 401 authorization avec Zammad 3.4, de le déprécier durement avec 3.5 (ou 3.6) et de passer à 403.
Nous devons en discuter davantage en interne.

D'autres réflexions à ce sujet, quelqu'un?

Ce sont de bonnes nouvelles! Cela me semble bon.

Pour vous tenir au courant: nous allons l'implémenter avec la prochaine version 4.0.

À des fins de mise en œuvre interne: https://thoughtbot.com/blog/forbidden-kisses-http-fluency-in-clearance

Corrigé avec le commit ci-dessus. Nous avons pris le risque et amélioré certains des messages d'erreurs 401 , mais fondamentalement, la seule chose que nous avons changée était les erreurs de non-authentification en 403 Forbidden .

Vous pouvez tester cela avec le dernier package develop dans environ 30 minutes à partir de maintenant. Veuillez noter qu'il s'agit d'une branche fonctionnelle et non stable. Assurez-vous donc d'avoir une sauvegarde et attendez-vous au pire :) Au plaisir d'entendre vos commentaires!