-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a deny page #2319
Comments
Nice idea, it was something I had in mind for a while! Technical implementation would require that Authelia sends the appropriate redirect instead, we should also create a specific react layout for the page so we can easily adjust it without affecting the main pages. |
Hey! Been thinking about this for a while, would be keen to give it a crack. Only thing I'm needing design assistance on is the networking behaviour. My thought is redirect to a 'Access Denied' page served on the same hostname as Authelia on webpage request, but on API requests still return the standard 403? |
Maybe for the sake of re-usability and translatability it would be beneficial to create a generic error path which takes an error_code in this instance the value would be The complication is always going to be how it's handled within each proxy. The flow particularly I think realistically we can redirect users in this instance to where they need to be, take a look at the more modern nginx examples for instance. |
I'd originally been on the fence about doing that but sure thing I'm not familiar with how nginx handles custom 403 pages that are more than a single html page, but I'll have a look around, I'll shout out if I need further clarification, thanks |
Check out this file here: https://653ff4d88e4e120008fabca3--authelia-staging.netlify.app/integration/proxies/nginx/#authelia-authrequestconf ## Modern Method: Set the $redirection_url to the Location header of the response to the Authz endpoint.
auth_request_set $redirection_url $upstream_http_location;
## Modern Method: When there is a 401 response code from the authz endpoint redirect to the $redirection_url.
error_page 401 =302 $redirection_url;
## could be added
error_page 403 =302 $redirection_url;
`` |
I'm not 100% certain this will work for all proxies, but we've recently given ourselves the best chance possible to support all of them by including a separate implementation for each of them, part of the motivation was this particular use case I believe. |
That's plenty for me to go on! I'm looking at the logs for the standalone suite trying to understand 401 -> 302 behaviour (so I can understand how 403 should work), Authelia logs say returning 401 but the browser is getting a 302. Good to know this is probably the proxy. I was hoping it would be a catch-all but I guess not... What's the general rule of thumb for developers supporting other proxies? If I got this working with the basic Nginx and possibly Envoy, should I also try with other suites before a PR? Just making sure I don't bite off more than I can chew... I might take a look at my deployed Authelia logs to see what happens behind Istio/Envoy. Might be able to achieve a similar thing with an EnvoyFilter although I do see a lot of complaints about 403 status pages not being part of istio. |
Kind of writing these here as public notes for later: Possible Implementations with rewriting status codes from 403 to 302, not yet tested but to be explored: NGINX as posted by @james-d-elliott above:
Envoy: Istio: Caddy: Haven't looked into any others but figured its a good start |
Regarding HAProxy: this serverfault post talks about redirecting when a 404 is received by backend. I guess this would work also for 403 and/or 401.
|
I believe this needs to be modified slightly because you should be looking at the status code received from |
When you first replied it completely jumped over me that it was your issue originally, I've got this working in the standalone (NGINX based) suite. Needs a decent amount of cleaning up before it's ready so could still be a month or two away, but I am slowly chipping away now that I've got the design + logic figured out. I'll give the HAProxy suite a crack next since there's no istio suite to test for my environment, then I'll post and get your feedback :) |
When a user does not have the required permissions, a redirection url to a new 'Access Denied' page is passed back to the reverse proxy along with the 403 error code. This follows the same sequence as an unauthenticated user getting redirected to the login. The Access Denied page presents the user with an option to logout, as well as the details of the page they were denied access to. Work includes a slight refactor of authz handlers to allow for code reuse. Also includes a simple 'demo home' button injected into the development login page to allow for easier navigation back to home.example.com for the Standalone suite. Fixes authelia#2319. Signed-off-by: Rocket Proto <rocketproto@gmail.com>
Feature Request
Description
I would like that Authelia display a beautiful "Access denied" page when a user has no permission to access a resource, as defined by the rules.
Use Case
Currently we configured HAProxy to return the default 403 page. We could create a custom 403 page, but it would make sense that this page use the same design as Authelia.
The text was updated successfully, but these errors were encountered: