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
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx