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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
