[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 Created: 25/Nov/11  Updated: 07/Dec/15  Resolved: 07/Dec/15

Status: Closed
Project: Magnolia
Component/s: security
Affects Version/s: 4.5, 5.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Daniel Lipp Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Explanation on why some tests of bundle now fail.eml    
Issue Links:
relation
is related to MAGNOLIA-3863 An additional security filter which h... Closed
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)
Date of First Response:

 Comments   
Comment by Magnolia International [ 03/Dec/13 ]

Here's an email Daniel reminded me off with an explanation I gave (tried to give) about why some integration tests started failing after fixing MAGNOLIA-3863. The situation is(was?) the following:

After the changes made in MAGNOLIA-3863 - we started consistently always returning a 403 code. IMO this is more correct than it was - we were using 401 and 403 semi-randomly before, although they have different semantics. While debatable, [Wikipedia|] makes a sensible distinction:

401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided.[2] The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.
[...]
403 Forbidden
The request was a valid request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2] On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g., a recognized user attempting to access restricted content).

So what we should do is return 401 when a user is not authenticated yet and tries to access a resource to which he has no access, and 403 when she's already logged in.

This would help integration (WebDAV, REST, ...) and would also allow us to avoid rendering a silly login form when a logged-in user tries to access a resource they simply don't have access to, without even an indication of why they see this form in the first place.

Comment by Michael Mühlebach [ 07/Dec/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:50:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.