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