Unable to use subrequest authentication for proxied site

Francis Daly francis at daoine.org
Mon Sep 21 08:52:32 UTC 2020

On Sun, Sep 20, 2020 at 10:33:43AM -0700, Lists wrote:
> 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,

> > > 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"?

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

Great that you identified the problem and the fix; thanks for sharing
with the list that that was the problem here. That will help the next
person with a similar unexpected behaviour.

> 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? 

The auth_request part of nginx does not care whether the response body
is a login page, or an animated gif of a smiling face. It only cares
about the http response code.

200 == successful result, as far as it is concerned.

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

That's probably the right thing to do overall; except that you probably
will not control what the typical browser shows for (e.g.) a 401 response.

If the rest of your application already works with the 200 "please login"
screen, then potentially you could send the 401 to nginx in response to
the auth_request request; and add an "error_page 401 = /login_screen;"
in the nginx location{}, and make the nginx subrequest for /login_screen
return that "please login" with a 200 status.

http://nginx.org/r/error_page for more information on that option.

That could maintain the control that you currently have over what the
end-user sees, while still having nginx allow the expected requests
based on what the upstream says.

Good luck with it,

Francis Daly        francis at daoine.org

More information about the nginx mailing list