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