Zammad: Respuestas HTTP 401 que causan problemas con la autenticación básica

Creado en 24 mar. 2020  ·  12Comentarios  ·  Fuente: zammad/zammad

Infos:

  • Versión de Zammad utilizada: 3.2.0
  • Método de instalación (fuente, paquete, ..): Desde la fuente usando Ruby 2.5.5, detrás de nginx rproxy.
  • Sistema operativo: Ubuntu 18.04.4 LTS (biónico)
  • Base de datos + versión: postgres 9.5.21
  • Versión de Elasticsearch: 5.6.16
  • Navegador + versión: Google Chrome 80.0.3987.132

Comportamiento esperado:

Zammad se integra sin problemas con una capa de autenticación básica . Por lo tanto, nunca se utiliza el código de estado "HTTP 401 No autorizado". Como alternativa, el código de estado 403 sería un reemplazo adecuado.

Comportamiento real:

En general, Zammad no tiene muchos problemas cuando se combina con la autenticación básica. Pero hay algunos casos en los que se responde a una solicitud con un código de estado 401 y el usuario actual se ve obligado a volver a ingresar sus credenciales de autenticación básicas.

El código base se puede buscar fácilmente para el estado 401 (o unauthorized ):
https://github.com/zammad/zammad/search?l=Ruby&q=%3Aunauthorized

Pasos para reproducir el comportamiento:

  • Configure una instancia de Zammad y colóquela detrás de la autenticación básica

LUEGO

  • Intente iniciar sesión con credenciales incorrectas
  • La aplicación muestra una página con el código de estado 401 y lo obliga a volver a ingresar las credenciales de autenticación básicas.

O

  • Crea un ticket asignado a un grupo donde la persona 1 tiene acceso
  • La persona 1 interactúa con ese ticket
  • Mueva ese boleto a otro grupo que no sea accesible para la persona 1
  • La persona 1 seguirá viendo una solicitud 401 al ticket anterior en su descripción general de Zammad, lo que lo desconectará de la autenticación básica.

Sí, estoy seguro de que se trata de un error y no se solicita una función o es una pregunta general.

API bug verified

Comentario más útil

¡Hola, chicos! Gracias por la valiosa información y descripciones. Leí el RFC y todavía estaba un poco confundido acerca de las diferencias entre 401 y 403. Sin embargo, encontré esta gran explicación en StackOverflow. Cita:

Hay un problema con 401 No autorizado, el código de estado HTTP para errores de autenticación. Y eso es todo: es para autenticación, no autorización.

Eso lo lleva al grano. Zammad usa 401 para authorization errores. Esto es técnicamente incorrecto y, por lo tanto, es un error. Reabriré el problema.

Sin embargo, debemos comprobar el impacto. Supongo que este es un cambio importante debido a todas las implementaciones y consumidores de API que existen.
Mi plan actual es depreciar suavemente 401 authorization con Zammad 3.4, desaprobarlo con 3.5 (o 3.6) y cambiar a 403.
Necesitamos discutir esto más internamente.

¿Más pensamientos sobre esto, alguien?

Todos 12 comentarios

Actualice su primer artículo para mantener su información de instalación exacta - "cualquiera" no es realmente adecuado en este momento - lo siento. :)

Además, proporcione la configuración completa de su servidor web (y háganos saber cuál está utilizando). En este momento huele un poco a una cuestión técnica, pero me gustaría estar completamente seguro. Sin embargo, para eso necesito todo. ;)

Gracias.

Hola de nuevo,
Actualicé la descripción del problema, ¡perdón por la falta inicial!
Mejor

Gracias por la actualización. ¿La configuración de su servidor web es nuestra configuración predeterminada extendida por autenticación básica? ¿Le importaría proporcionar esa configuración de vhost también? Solo para estar seguro de que no me estoy perdiendo nada.

¡Gracias!

Sí, básicamente es solo configuración predeterminada de Zammad + autenticación básica. Aquí está la configuración 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;
}

Examinamos eso de nuevo.
Nuestra suposición (como escribió Michael) sería no devolver un HTTP 401 (lo que hace que el navegador crea que las credenciales de autenticación básicas proporcionadas son incorrectas), sino devolver HTTP 403 prohibido.

Si lo viera correctamente, esto significaría

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

debe ser reemplazado con
respond_to_exception(e, :forbidden)

RFC dice que los navegadores deben comportarse de manera diferente (https://tools.ietf.org/html/rfc7231#section-6.5.3): "Si se proporcionaron credenciales de autenticación en la solicitud, el servidor las considera insuficientes para otorgar acceso. El cliente DEBE NO repita automáticamente la solicitud con las mismas credenciales ".

Sin embargo, tuvimos el mismo problema en otro proyecto la semana pasada y 403 obras.
Si no ve otros problemas al devolver un 403, podemos emitir un PR.

Mejor

Perdón por demorarme tanto.
Tenga en cuenta que este no es un problema relacionado con Zammad (basado en aplicaciones), sino un "problema de backend" en su nginx.

Las solicitudes de autenticación para la autenticación básica nunca llegan a Zammad como aplicación, pero ya finalizan (y son verificadas por) su nginx o cualquier otro servidor web que use.

Por lo tanto, cambiar el código fuente, en mi opinión, no resuelve su problema en absoluto.
Técnicamente, un 401 no autorizado es correcto por lo que puedo decir (aunque entiendo que querrías un 403).

Ver también:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

Por cierto:
Solo para verificar, comenté completamente las partes del proxy de Zammad para asegurarme de que el backend de Zammad no pueda responder. El resultado con 401 es el mismo y, por lo tanto, es culpa de nginx. :)

Cerrando ya que esto no es un error sino una cuestión técnica.

Hola @MrGeneration ,
Gracias por mirar en esto.

Si bien entiendo que este problema parece estar fuera del alcance de la aplicación Zammad, sigo pensando que es causado por él (y no por Ngnix). Intentaré explicar por qué:

Supongamos que nuestro ngnix _no_ está configurado para usar la autenticación básica. En este caso, ambos estamos de acuerdo en que la aplicación Zammad ("detrás" del ngnix) simplemente funciona bien.

Ahora, habilitamos la autenticación básica agregando la configuración indicada anteriormente a nuestro ngnix. Tenga en cuenta que, incluso ahora, casi todo sigue funcionando como se esperaba, incluidas las autenticaciones (inicio de sesión básico y Zammad) y la propia aplicación Zammad.

El problema que traté de describir anteriormente es causado a veces más tarde (¡por Zammad!) Cuando la aplicación muestra una página con el código de estado 401. En este caso, _cualquier servidor web_ con autenticación básica habilitada se ve obligado a cerrar la sesión.

Estoy de acuerdo en que semánticamente hablando 401 suena "perfecto" en este caso. Técnicamente hablando, causa problemas inevitables con la autenticación básica y debe reemplazarse con 403.
Vuelva a abrir este problema, ya que también podría afectar la UX de la aplicación Zammad para muchos usuarios.

@thorsteneckel ¿cuál es tu opinión sobre esto?

¡Hola, chicos! Gracias por la valiosa información y descripciones. Leí el RFC y todavía estaba un poco confundido acerca de las diferencias entre 401 y 403. Sin embargo, encontré esta gran explicación en StackOverflow. Cita:

Hay un problema con 401 No autorizado, el código de estado HTTP para errores de autenticación. Y eso es todo: es para autenticación, no autorización.

Eso lo lleva al grano. Zammad usa 401 para authorization errores. Esto es técnicamente incorrecto y, por lo tanto, es un error. Reabriré el problema.

Sin embargo, debemos comprobar el impacto. Supongo que este es un cambio importante debido a todas las implementaciones y consumidores de API que existen.
Mi plan actual es depreciar suavemente 401 authorization con Zammad 3.4, desaprobarlo con 3.5 (o 3.6) y cambiar a 403.
Necesitamos discutir esto más internamente.

¿Más pensamientos sobre esto, alguien?

¡Esas son buenas noticias! Suena bien para mí.

Para mantenerlo informado: implementaremos esto con la próxima versión 4.0.

Para propósitos de implementación interna: https://thoughtbot.com/blog/forbidden-kisses-http-fluency-in-clearance

Corregido con el compromiso anterior. Aprovechamos la oportunidad y mejoramos algunos de los mensajes de errores de 401 , pero básicamente lo único que cambiamos fueron los errores de no autenticación a 403 Forbidden .

Puede probar esto con el último paquete develop en unos 30 minutos a partir de ahora. Tenga en cuenta que esta es una rama que funciona y no es estable. Por lo tanto, asegúrese de tener una copia de seguridad y espere lo peor :) ¡Esperamos escuchar sus comentarios!

¿Fue útil esta página
0 / 5 - 0 calificaciones