Unable to use subrequest authentication for proxied site

[Lists]

See reply below 

On Sunday, September 20, 2020 8:29:32 AM PDT Francis Daly wrote:
> 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?

Hmm, 

> 
> > 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.)

Turns out this is *exactly* what was happening - Ugh. I hadn't published an 
"open" security profile for the /external/etherpad.php URI and it was 
responding with a login page and http code 200. 

So publishing a security profile for that page fixed the problem and now (with 
the correct proxy adding "/p/" at the end) and it seems to be passing all the 
tests I expect. 

But if the result was a login screen instead of a successful result, I'm 
thinking it *still* should have (not) worked. How is getting a login screen 
instead of the expected result a "successful" request? 

So I'm doing an audit to update my authentication code to return proper http 
response codes instead of just friendly end-user http response "200" pages. 

I thank you for your time and consideration. 

>   curl -i -H 'X-Original-URI: /p/MyPadId?sess_id=INVALID' https://
mydomain.dom/external/etherpad.php
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200920/967fa6ab/attachment.bin>