-
New Feature
-
Resolution: Fixed
-
Neutral
-
None
-
None
-
-
Empty show more show less
Rationale: we currently have 2 security filters, which among other things have duplicated configuration (the "callback", which presents the client with a login form). On top of this, with MAGNOLIA-3858, we realized there are cases where we also need to handle an AccessDeniedException which can be thrown between those two filters (i.e from a servlet; example: the RSS servlet, which wraps an AccessDeniedException when the content it needs to access to generate a feed is not authorized for the current user).
Implementation:
- the 2 existing filters will not execute the callbacks anymore. They will merely set a 401 or 403 http code in the response.
- the new filter, place in front of those two, will check the response's status, as well as catch {{AccessDeniedException}}s that might have been thrown down the filter chain, and execute an appropriate callback.
This way, any component down the filter chain can set a 401 or 403 response code, or throw an AccessDeniedException, and we'll send an appropriate response to the user.
TBD: how does this behave if rendering has begun ? It is expected that an AccessDeniedException or other exception happening at that level would not be let up the chain.
- depends upon
-
MAGNOLIA-3876 ExceptionUtil additions
- Closed
-
MAGNOLIA-3875 Re-export config.server.filters.xml cleanly
- Closed
- is causing
-
MAGNOLIA-3967 core: after 4.4.6 update to 4.5 adminCentral is no longer accessible
- Closed
-
MGNLWEBDAV-29 Authorization for WebDAV access is broken
- Closed
- is depended upon by
-
MAGNOLIA-3858 Support for multiple HttpClientCallback, where the callback itself decides if it handles the request
- Closed
- is related to
-
MAGNOLIA-3890 Precisely define what error code we want to return in what situation: with current imp l's we only return 403's - no 401's
- Closed
- supersedes
-
MAGNOLIA-2718 Configuration for uriSecurityFilter and contentSecurityFilter is redundant
- Closed