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.
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
LUEGO
O
Sí, estoy seguro de que se trata de un error y no se solicita una función o es una pregunta general.
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!
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:
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?