简体   繁体   English

Oauth2-proxy - 重定向到上游 url 时出现 404 错误(Django 应用程序 web 页面)

[英]Oauth2-proxy - 404 error when redirecting to upstream url (Django application web page)

I'm trying to protect a Django application with oauth2-proxy我正在尝试使用 oauth2-proxy 保护 Django 应用程序

In the oauth2-proxy configuration: (version 7.2.1 or 7.3.0)在 oauth2-proxy 配置中:(版本 7.2.1 或 7.3.0)

When the upstream url is set to something like this: --upstream="http://127.0.0.1:8000" the redirection works fine.当上游 url 设置为以下内容时: --upstream="http://127.0.0.1:8000" 重定向工作正常。 (and it returns a home page I have defined in the application ) (它返回一个我在应用程序中定义的主页)

But, if I use an upstream like this: --upstream="http://127.0.0.1:8000/hello" it returns 404 error instead of the hello page that is also defined in the application但是,如果我使用这样的上游: --upstream="http://127.0.0.1:8000/hello" 它返回 404 错误,而不是应用程序中定义的 hello 页面

The page http://127.0.0.1:8000/hello is working fine when invoked directly and it returns "GET /hello HTTP/1.1" 200 136页面http://127.0.0.1:8000/hello在直接调用时工作正常,它返回“GET /hello HTTP/1.1”200 136

So I would say it is not a problem with the page.所以我会说这不是页面的问题。

This is the command line I'm using:这是我正在使用的命令行:

oauth2-proxy.exe ^
    --http-address=127.0.0.1:4180 ^
    --email-domain=* ^
    --cookie-secure=false ^
    --cookie-secret=adqeqpioqr809718 ^
    --upstream="http://127.0.0.1:8000/hello" ^
    --redirect-url=http://127.0.0.1:4180/oauth2/callback ^
    --oidc-issuer-url=http://127.0.0.1:28081/auth/realms/testrealm ^
    --insecure-oidc-allow-unverified-email=true ^
    --provider=keycloak-oidc ^
    --client-id=oauth2_proxy ^
    --ssl-insecure-skip-verify=true ^
    --client-secret=L2znXLhGX4N0j3nsZYxDKfdYpXHMGDkX ^
    --skip-provider-button=true 

When the oauth2-proxy succeeds to redirect (--upstream="http://127.0.0.1:8000"), I get the page and the following output:当 oauth2-proxy 成功重定向 (--upstream="http://127.0.0.1:8000") 时,我得到页面和以下 output:

This is the output for the oauth2-proxy:这是 oauth2 代理的 output:

[2022/09/08 10:52:06] [proxy.go:89] mapping path "/" => upstream "http://127.0.0.1:8000"
[2022/09/08 10:52:06] [oauthproxy.go:148] OAuthProxy configured for Keycloak OIDC Client ID: oauth2_proxy
[2022/09/08 10:52:06] [oauthproxy.go:154] Cookie settings: name:_oauth2_proxy secure(https):false httponly:true expiry:168h0m0s domains: path:/ samesite: refresh:disabled
[2022/09/08 10:57:01] [oauthproxy.go:866] No valid authentication in request. Initiating login.
127.0.0.1:54337 - 9bbfcf75-da91-487a-a55e-40472e4adb23 - - [2022/09/08 10:57:01] 127.0.0.1:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 302 380 0.001
127.0.0.1:54337 - e0d8ed12-e4dd-4da6-9fbb-cf689fc53f8f - mail@gmail.com [2022/09/08 10:57:09] [AuthSuccess] Authenticated via OAuth2: Session{email:mail@gmail.com user:93547bcc-2441-414a-9149-c7533c4f5d23 PreferredUsername:testuser token:true id_token:true created:2022-09-08 10:57:09.789934 -0300 -03 m=+303.019857301 expires:2022-09-08 11:02:09.7839238 -0300 -03 m=+603.013847101 refresh_token:true groups:[role:offline_access role:uma_authorization role:default-roles-testrealm role:account:manage-account role:account:manage-account-links role:account:view-profile]}
[2022/09/08 10:57:09] [session_store.go:163] WARNING: Multiple cookies are required for this session as it exceeds the 4kb cookie limit. Please use server side session storage (eg. Redis) instead.
127.0.0.1:54337 - e0d8ed12-e4dd-4da6-9fbb-cf689fc53f8f - - [2022/09/08 10:57:09] 127.0.0.1:4180 GET - "/oauth2/callback?state=ahuKzCYr7jR4P4mmjniIt67TttZKyxGv4mLfEwKlQio%3A%2F&session_state=86ac9bd1-9756-4916-83e9-ec0496b5b767&code=df3940e5-58f5-49ac-a821-5607f0f2faae.86ac9bd1-9756-4916-83e9-ec0496b5b767.cd30a162-8e4d-4a2d-bff6-168e444aed92" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 302 24 0.029
127.0.0.1:54337 - d58ace6e-afe9-4737-9b12-dbc17fdd0ca2 - mail@gmail.com [2022/09/08 10:57:09] 127.0.0.1:4180 GET / "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 200 138 0.005

On the Django side I get:在 Django 方面,我得到:

**"GET / HTTP/1.1" 200 138**


When the oauth2-proxy fails to redirect --upstream="http://127.0.0.1:8000/hello"), I get the following output:当 oauth2-proxy 无法重定向 --upstream="http://127.0.0.1:8000/hello") 时,我得到以下 output:

This is the output for the oauth2-proxy:这是 oauth2 代理的 output:

[2022/09/08 10:33:58] [proxy.go:89] mapping path "/hello" => upstream "http://127.0.0.1:8000/hello"
[2022/09/08 10:33:58] [oauthproxy.go:148] OAuthProxy configured for Keycloak OIDC Client ID: oauth2_proxy
[2022/09/08 10:33:58] [oauthproxy.go:154] Cookie settings: name:_oauth2_proxy secure(https):false httponly:true expiry:168h0m0s domains: path:/ samesite: refresh:disabled
[2022/09/08 10:37:20] [oauthproxy.go:866] No valid authentication in request. Initiating login.
127.0.0.1:53615 - 54c0f3d8-b3c0-4d48-8353-fe69be0e4500 - - [2022/09/08 10:37:20] 127.0.0.1:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 302 380 0.001
127.0.0.1:53615 - 0bec934e-05a3-4cc8-9306-fffc28597c8f - mail@gmail.com [2022/09/08 10:37:28] [AuthSuccess] Authenticated via OAuth2: Session{email:mail@gmail.com user:93547bcc-2441-414a-9149-c7533c4f5d23 PreferredUsername:testuser token:true id_token:true created:2022-09-08 10:37:28.6527488 -0300 -03 m=+210.486252601 expires:2022-09-08 10:42:28.6468518 -0300 -03 m=+510.480355601 refresh_token:true groups:[role:offline_access role:uma_authorization role:default-roles-testrealm role:account:manage-account role:account:manage-account-links role:account:view-profile]}
[2022/09/08 10:37:28] [session_store.go:163] WARNING: Multiple cookies are required for this session as it exceeds the 4kb cookie limit. Please use server side session storage (eg. Redis) instead.
127.0.0.1:53615 - 0bec934e-05a3-4cc8-9306-fffc28597c8f - - [2022/09/08 10:37:28] 127.0.0.1:4180 GET - "/oauth2/callback?state=nox0LM3fIlVU1kamoLBaktByeLCcIWiBvRLdHFIuhd4%3A%2F&session_state=808c0654-c9e7-4593-b5dc-95d3231438ea&code=e220414d-e949-4e2d-8d33-55de96f8f5d4.808c0654-c9e7-4593-b5dc-95d3231438ea.cd30a162-8e4d-4a2d-bff6-168e444aed92" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 302 24 0.024
127.0.0.1:53615 - 9454773f-cade-46fe-870f-70d09fc49ffb - mail@gmail.com [2022/09/08 10:37:28] 127.0.0.1:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27" 404 19 0.000

On the Django side I get:在 Django 方面,我得到:

Nothing.没有什么。 As the Django app is never reached and so there are no logs.由于从未到达 Django 应用程序,因此没有日志。

Could you please help me find out what could be happening?你能帮我看看会发生什么吗? I will really appreciate it!!我会很感激的!!

It doesn't seem to be a problem with the application, as the pages work fine when invoked directly.这似乎不是应用程序的问题,因为直接调用时页面工作正常。 If it is a mistake in my oauth2-proxy command line/configuration, I would appreciate someone points me to the error, so I can correct it.如果这是我的 oauth2-proxy 命令行/配置中的错误,我会很感激有人指出错误,所以我可以纠正它。

Otherwise, any hint would also be much appreciated.否则,任何提示也将不胜感激。

The only thing I've noticed in the logs of oauth2-proxy is that no matter what I put in the --upstream, the final GET (I think it is the redirection to the upstream) is as follows: GET - "/"... it is the same in both attempts, and it only succeeds in the first one, because it matches the [proxy.go:89] mapping path "/"我在 oauth2-proxy 的日志中唯一注意到的是,无论我在 --upstream 中放入什么,最终的 GET(我认为是对上游的重定向)如下:GET - "/" ...两次尝试都一样,只在第一次成功,因为它匹配[proxy.go:89]映射路径“/”

The reason it was giving the 404 error, was that the configuration --upstreams points to a url to which the proxy is going to pass the request once authenticated, but it is not going to redirect to that address unless you specifically ask for it in the original request.它给出 404 错误的原因是配置 --upstreams 指向一个 url 代理将在经过身份验证后将请求传递到该地址,但除非您特别要求,否则它不会重定向到该地址原始请求。

So the correct way of making the request is http://127.0.0.1:4180/hello , which is including the whole path to the endpoint you want to reach.所以发出请求的正确方法是http://127.0.0.1:4180/hello ,其中包括您想要到达的端点的整个路径。 (instead of for example http://127.0.0.1:4180 ) (而不是例如http://127.0.0.1:4180

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM