Unable to use subrequest authentication for proxied site

[Francis Daly]

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,

	f
-- 
Francis Daly        francis at daoine.org