[MAGNOLIA-4395] Security filters should set 401 or 403 more appropriately Created: 26/Apr/12 Updated: 27/Apr/12 Resolved: 27/Apr/12 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 4.5.2 |
| Fix Version/s: | 4.5.3 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Magnolia International | Assignee: | Daniel Lipp |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
Currently, both URISecurityFilter and ContentSecurityFilter inadequately set a 403 http status when a user doesn't have access to a given resource. The problem lies in the fact that it doesn't distinguish between anonymous and logged-in access. An anonymous request should most likely end up with a 401 code ("needs authentication"), whereas when the user is already logged in, a more correct return code would be 403 ("not authorized"). While this might lead to some security concerns (one can discover the existence of protected content), it also leads to basic authorization simply not working with some client. Browsers, for example, will only display the auth dialog when receiving a 401, not a 403 - or so it seems, anyway. |
| Comments |
| Comment by Magnolia International [ 26/Apr/12 ] |
|
Sorry, hadn't seen |
| Comment by Magnolia International [ 27/Apr/12 ] |
|
See |
| Comment by Jan Haderka [ 27/Apr/12 ] |
|
Since there's more then one filter manipulating response code, I'd see it as more prudent and easier to maintain to have such behavior (swapping 401 for 404) in separate filter should anyone need such functionality. |