Zammad: 기본 인증에 문제를 일으키는 HTTP 401 응답

정확한 설치 정보를 유지하기 위해 첫 번째 기사를 업데이트하십시오. "모든"은 현재로서는 적합하지 않습니다. 죄송합니다. :)

또한 전체 웹 서버 구성을 제공하고 어떤 구성을 사용 중인지 알려주십시오. 지금은 기술적 인 질문과 같은 냄새가납니다.하지만 완전히 확인하고 싶습니다. 그러나 그것을 위해서는 모든 것이 필요합니다. ;)

감사.

안녕하세요,
문제 설명을 업데이트했습니다. 처음에는 문제가 없어서 죄송합니다!
베스트

업데이트 해주셔서 감사합니다. 웹 서버의 구성은 기본 인증으로 확장 된 기본 구성입니까? 해당 가상 호스트 구성도 제공 하시겠습니까? 내가 뭔가를 놓치고 있지 않은지 확인하기 위해서.

감사!

예, 기본적으로 Zammad 기본 구성 + 기본 인증입니다. 다음은 가상 호스트 구성입니다.

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

우리는 그것을 다시 조사했습니다.
Michael이 쓴 것처럼 우리의 추측은 HTTP 401 (브라우저가 주어진 기본 인증 자격 증명이 올바르지 않다고 믿게 함)을 반환하지 않고 HTTP 403 금지를 반환하는 것입니다.

내가 올바르게 본다면 이것은

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

대체해야합니다
respond_to_exception(e, :forbidden)

RFC는 브라우저가 다르게 동작해야한다고 말합니다 (https://tools.ietf.org/html/rfc7231#section-6.5.3) : "인증 자격 증명이 요청에 제공된 경우 서버는 액세스 권한을 부여하기에 부족하다고 간주합니다. 클라이언트는 SHOULD 동일한 자격 증명으로 요청을 자동으로 반복하지 마십시오. "

하지만 지난주에 다른 프로젝트에서 같은 문제가 있었고 403 작품이 있습니다.
403을 반환하는 데 다른 문제가없는 경우 PR을 발행 할 수 있습니다.

베스트

너무 오래 걸려서 죄송합니다.
이것은 Zammad 관련 문제 (응용 프로그램 기반)가 아니라 nginx의 "백엔드 문제"입니다.

기본 인증에 대한 인증 요청은 응용 프로그램으로 Zammad에 도달하지 않지만 이미 nginx 또는 사용하려는 다른 웹 서버에서 종료되고 확인됩니다.

따라서 소스 코드를 변경하는 것은 문제를 전혀 해결하지 못하는 것 같습니다.
기술적으로 승인되지 않은 401은 내가 말할 수있는 것과 맞습니다 (당신이 403을 원한다고 이해하더라도).

또한보십시오:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

그건 그렇고 :
다시 한 번 확인하기 위해 Zammad의 백엔드가 응답 할 수 없도록 Zammad 프록시 부분을 완전히 주석 처리했습니다. 401의 결과는 동일하므로 nginx의 오류입니다. :)

이것은 버그가 아니라 기술적 인 질문이므로 마무리합니다.

안녕하세요 @MrGeneration ,
조사해 주셔서 감사합니다.

이 문제는 Zammad 응용 프로그램의 범위를 벗어난 것처럼 보이지만 여전히 Ngnix가 아닌이 문제로 인해 발생한다고 생각합니다. 이유를 설명하려고합니다.

ngnix가 기본 인증을 사용하도록 구성되어 있지 않다고 가정 해 보겠습니다. 이 경우 우리 둘 다 Zammad 응용 프로그램 (ngnix "뒤")이 제대로 작동한다는 데 동의합니다.

이제 위에서 언급 한 구성을 ngnix에 추가하여 기본 인증을 활성화합니다. 지금도 인증 (기본 및 Zammad 로그인)과 Zammad 애플리케이션 자체를 포함하여 거의 모든 것이 예상대로 작동합니다.

앞서 설명하려고했던 문제는 응용 프로그램이 상태 코드가 401 인 페이지를 렌더링 할 때 나중에 (Zammad!에 의해) 발생하는 경우가 있습니다.이 경우 기본 인증이 활성화 된 _any webserver_가 강제로 로그 아웃됩니다.

나는 의미 론적으로 말하는 401이이 경우에 "정확히"들리는 것에 동의합니다. 기술적으로 말하면 기본 인증에 불가피한 문제가 발생하므로 403으로 대체해야합니다.
많은 사용자의 Zammad 응용 프로그램의 UX에도 영향을 미칠 수 있으므로이 문제를 다시여십시오.

@thorsteneckel 이것에 대한 당신의 의견은 무엇입니까?

얘들 아! 귀중한 정보와 설명에 감사드립니다. RFC를 읽었고 401과 403의 차이점에 대해 약간 혼란 스러웠습니다. 그러나 StackOverflow 에서이 훌륭한 설명 을 발견

인증 오류에 대한 HTTP 상태 코드 인 401 Unauthorized에 문제가 있습니다. 그리고 그것은 단지 인증을위한 것이지 인증을위한 것입니다.

그것은 요점을 가져옵니다. Zammad는 authorization 오류에 401을 사용합니다. 이것은 기술적으로 잘못되었으므로 버그입니다. 문제를 다시 열어 보겠습니다.

그러나 영향을 확인해야합니다. 나는 이것이 모든 구현과 API 소비자 때문에 획기적인 변화라고 가정합니다.
내 현재 계획은 Zammad 3.4에서 401 authorization 를 소프트 비추천하고 3.5 (또는 3.6)로 하드 비추천하고 403으로 전환하는 것입니다.
내부적으로 더 논의해야합니다.

이것에 대한 추가 생각?

좋은 소식입니다! 나에게 좋은 소리.

최신 소식을 계속 확인하려면 다음 4.0 릴리스에서이를 구현할 것입니다.

내부 구현 목적 : https://thoughtbot.com/blog/forbidden-kisses-http-fluency-in-clearance

위의 커밋으로 수정되었습니다. 우리는 기회를 잡고 401 오류 메시지 중 일부를 개선했지만 기본적으로 변경된 유일한 것은 비인증 오류가 403 Forbidden 입니다.

지금부터 약 30 분 안에 최신 develop 패키지로이를 테스트 할 수 있습니다. 이것은 작동하는 분기이며 안정적이지 않습니다. 따라서 백업이 있는지 확인하고 최악의 상황을 예상하십시오. :) 피드백을 기다리겠습니다!