Unable to use subrequest authentication for proxied site
    Francis Daly 
    francis at daoine.org
       
    Sun Sep 20 15:29:32 UTC 2020
    
    
  
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 at daoine.org
    
    
More information about the nginx
mailing list