[MGNLGQL-52] Return short error message for content walled off by access rights Created: 26/Aug/20  Updated: 21/Sep/20  Resolved: 21/Sep/20

Status: Closed
Project: Magnolia GraphQL
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Neutral
Reporter: Martin Drápela Assignee: Robert Šiška
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by MGNLGQL-32 DOC: Create GraphQL endpoint page Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: GraphQL Phase 1
Sprint: HL & LD 11
Story Points: 3

 Description   

Currently, a relatively long stacktrace is returned (50kB or so), if the requested content, e.g. authors { name }

{
    bookshelf(id: "c2a5ea72-6611-4f70-8005-42e8694fc610") {
        title
        authors {
            name
        }
    }
}

resides in a repo (Authors) which the user role has no access to:

{
    "status": 500,
    "errors": [
        {
            "message": "Exception while fetching data (/bookshelf/authors) : javax.jcr.ItemNotFoundException: b1bc15d1-e2d4-4d20-8491-1a42689bb003",
            "path": [
                "bookshelf",
                "authors"
            ],
            "exception": {
                "cause": {
                    "cause": null,
                    "stackTrace": [
                        {
                            "methodName": "g ...

 

 

 



 Comments   
Comment by Robert Šiška [ 14/Sep/20 ]

Unfortunately, JCR doesn't allow you to check whether the item with given identifier is granted/denied by Access-Control. It just returns ItemNotFound as if the item wasn't there.

We could do permission checks when requesting by path, but then it would be little inconsistent, imho.

However, sending stacktraces in responses is indeed not ideal and we should prevent that in other scenarios too. So, I'll re-purpose this ticket to that.

Generated at Mon Feb 12 05:52:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.