Unable to use subrequest authentication for proxied site

[Lists]

Following up, after implementation and rollout. 

On Monday, September 21, 2020 1:52:32 AM PDT Francis Daly wrote:
> 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.

I've not seen that a 401 or whatever error code causes browsers to do "funny 
stuff". I've long had a mildly amusing 404 page, for example. 

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

In my case, if the nginx proxy auth request fails, there are other issues 
elsewhere in the app and a simple denied screen is almost certainly sufficient. 

As a side note, within the app, if you make a request and it gives you a login 
screen instead, it has an http_code of 401. But if you specifically ask for the 
login screen EG: /login.php then that's 200. It's only the case where the 
thing requested is different than the thing returned that it gives you a 401, 
403, or 404. 

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

Thank. I might do that at some point in the future but right now nginx is 
serving a subdomain within an iframe of the main app and so is not the primary 
page the user sees. 

In a *legitimate* use, anyway. the proxy auth is to thwart malicious use. 

Thanks again, 

Ben S 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200924/395202e3/attachment.bin>