On Sat, Sep 19, 2020 at 09:26:57AM -0700, Lists wrote:
Hi there,
> How do I configure nginx to use subrequest authentication for a reverse proxied
> application with websocket upgrades? The documentation doesn't seem to contain
> the information I need to do this.
I have not tested the websocket part, but the rest of it "Works For
Me" (see below); and the response that you report does not seem to be
restricted to websockets in your case.
> *********************************************************
> WHAT IS HAPPENING (Schenario 1)
> 3) /external/etherpad.php receives authentication request, gets X-Original-URI
> and validates the request, returning an http_code 200 when all is well.
>
> 4) Nginx attempts to resolve the request as a local file, can't find it, and
> returns 404 to the end user.
Does that return a 404, or something else, when /external/etherpad.php
does not return http_code 200?
> SCENARIO 1 NGINX CONFIG FILE
> location /p/ {
> auth_request /auth;
> auth_request_set $auth_status $upstream_status;
> }
That does not cause the request /p/MyPad to be proxy_pass'ed anywhere,
because there is no proxy_pass in this location.
> *********************************************************
> WHAT IS HAPPENING (Schenario 2: invalid session ID)
>
> 3) /external/etherpad.php receives authentication request, gets X-Original-URI
> and validates the request, returning an http_code 401.
Out of interest - if you make that request yourself, manually, do you see
the http 401; or do you see something like a http 200 with a message of
"this is a 401"?
(It's unlikely, but is the only thing I can think of right now that
might show why your test case differs from mine, below.)
curl -i -H 'X-Original-URI: /p/MyPadId?sess_id=INVALID' https://mydomain.dom/external/etherpad.php
> SCENARIO 2 NGINX CONFIG FILE
> ----------------------
This looks like it should be working -- with the caveat that the original
request of /p/MyPad will become just /MyPad when it gets to the upstream
server. If that's not what you are seeing on the upstream, then this is
not the config that is being used.
> location /p/ {
> auth_request /auth;
> auth_request_set $auth_status $upstream_status;
>
> # NOTE THAT THIS IS A COPY OF LOCATION / UNTIL THE END OF THIS BLOCK.
> proxy_pass http://192.168.122.61:9001/;
<snip>
> }
> location /auth {
> internal;
> proxy_pass https://mydomain.com/external/etherpad.php;
> proxy_pass_request_body off;
> proxy_set_header Content-Length "";
> proxy_set_header X-Original-URI $request_uri;
> }
An alternate test could be to (temporarily) remove that "internal;",
and look at the response from
curl -i https://etherpad.mydomain.com:9000/auth
and see if that shows anything odd.
My test setup was:
==
server {
listen 9001; # the upstream
return 200 "9001; I just got a request for $request_uri\n";
}
server {
listen 9002; # the auth service
if ($http_please) {
return 200 "ok\n";
}
return 403 "nope\n";
}
server {
listen 9003; # the public face
location / {
return 200 "9003; I just got a request for $request_uri\n";
}
location /p/ {
auth_request /auth;
proxy_pass http://127.0.0.1:9001/;
}
location /auth {
proxy_pass http://127.0.0.1:9002;
proxy_set_header Please $http_please;
}
}
==
and then
curl -i http://127.0.0.1:9003/p/aaa
gives me a 403 response, while
curl -i -H Please:yes http://127.0.0.1:9003/p/aaa
gives me a 200 response of "9001; I just got a request for /aaa".
So my auth_request returns 200 and the proxy_pass happens; or my
auth_request returns (in this case) 403 and the proxy_pass does not
happen.
Does your system respond differently, using this simplified test case?
Does "nginx -V" show anything unusual?
Cheers,
f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
