Gravsearch ForbiddenResource result and permissions of linked resources #1344

gfoo · 2019-06-05T15:44:16Z

With gravsearch, I get a ForbiddenResource when a user does not have enough rights to get a linked resource but enough rights to get the property linking this resource. With v2/resources endpoint it works correctly.

For example with this query, I get a ForbiddenResource if a user (group php-student) cannot view a Collection related to a Person (see expected result below).
n.b.: with Knora 7.0.0

PREFIX knora-api: <http://api.knora.org/ontology/knora-api/simple/v2#>
PREFIX ll: <http://0.0.0.0:3333/ontology/0113/lumieres-lausanne/simple/v2#>
CONSTRUCT {
  ?Person knora-api:isMainResource true .
  ?Person ll:isInCollection ?isInCollection .
  } WHERE {
 { BIND(<http://rdfh.ch/0113/A5nRGhSNSHqtDMDSFDC2sw> AS ?Person) }
  ?Person a knora-api:Resource .
  ?Person a ll:Person .
  OPTIONAL {
    ?Person ll:isInCollection ?isInCollection .
    ?isInCollection a ll:Collection .
  }
}

With a user from administrator group who has access to related Collections, we get this normal result:

{
    "@id": "http://rdfh.ch/0113/A5nRGhSNSHqtDMDSFDC2sw",
    "@type": "lumieres-lausanne:Person",
    "lumieres-lausanne:isInCollectionValue": [
        {
            "@id": "http://rdfh.ch/0113/A5nRGhSNSHqtDMDSFDC2sw/values/CSR-ZbLTRtSRigalj7BezQ",
            "@type": "knora-api:LinkValue",
            "knora-api:attachedToUser": {
                "@id": "http://rdfh.ch/users/lumieres-lausanne-admin"
            },
            "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director|D knora-admin:Creator|M http://rdfh.ch/groups/0113/lumieres-lausanne-phdstudent,http://rdfh.ch/groups/0113/lumieres-lausanne-researcher,http://rdfh.ch/groups/0113/lumieres-lausanne-student|V http://rdfh.ch/groups/0113/lumieres-lausanne-user,knora-admin:KnownUser,knora-admin:UnknownUser",
            "knora-api:linkValueHasTarget": {
                "@id": "http://rdfh.ch/0113/xYkKg_GfQ5az0FOqS1iOwA",
                "@type": "lumieres-lausanne:Collection",
                "knora-api:arkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/xYkKg_GfQ5az0FOqS1iOwA7"
                },
                "knora-api:attachedToProject": {
                    "@id": "http://rdfh.ch/projects/0113"
                },
                "knora-api:attachedToUser": {
                    "@id": "http://rdfh.ch/users/ZOk2hEFRRU2gwulwC6p43g"
                },
                "knora-api:creationDate": {
                    "@type": "xsd:dateTimeStamp",
                    "@value": "2019-05-29T14:04:52.413403Z"
                },
                "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director,knora-admin:Creator",
                "knora-api:userHasPermission": "CR",
                "knora-api:versionArkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/xYkKg_GfQ5az0FOqS1iOwA7.20190529T140452413403Z"
                },
                "rdfs:label": "103"
            },
            "knora-api:userHasPermission": "CR",
            "knora-api:valueCreationDate": {
                "@type": "xsd:dateTimeStamp",
                "@value": "2019-05-29T14:09:51.601709Z"
            }
        },
        {
            "@id": "http://rdfh.ch/0113/A5nRGhSNSHqtDMDSFDC2sw/values/HInELMP2QzKrHF4kDVRsPw",
            "@type": "knora-api:LinkValue",
            "knora-api:attachedToUser": {
                "@id": "http://rdfh.ch/users/lumieres-lausanne-admin"
            },
            "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director|D knora-admin:Creator|M http://rdfh.ch/groups/0113/lumieres-lausanne-phdstudent,http://rdfh.ch/groups/0113/lumieres-lausanne-researcher,http://rdfh.ch/groups/0113/lumieres-lausanne-student|V http://rdfh.ch/groups/0113/lumieres-lausanne-user,knora-admin:KnownUser,knora-admin:UnknownUser",
            "knora-api:linkValueHasTarget": {
                "@id": "http://rdfh.ch/0113/xBe0ry9VRlamJGP18lSuxQ",
                "@type": "lumieres-lausanne:Collection",
                "knora-api:arkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/xBe0ry9VRlamJGP18lSuxQ3"
                },
                "knora-api:attachedToProject": {
                    "@id": "http://rdfh.ch/projects/0113"
                },
                "knora-api:attachedToUser": {
                    "@id": "http://rdfh.ch/users/gZ3sFhIRR3eZQYvmoOmwBg"
                },
                "knora-api:creationDate": {
                    "@type": "xsd:dateTimeStamp",
                    "@value": "2019-05-29T14:04:55.516331Z"
                },
                "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director,knora-admin:Creator",
                "knora-api:userHasPermission": "CR",
                "knora-api:versionArkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/xBe0ry9VRlamJGP18lSuxQ3.20190529T140455516331Z"
                },
                "rdfs:label": "177"
            },
            "knora-api:userHasPermission": "CR",
            "knora-api:valueCreationDate": {
                "@type": "xsd:dateTimeStamp",
                "@value": "2019-05-29T14:09:51.601709Z"
            }
        },
        {
            "@id": "http://rdfh.ch/0113/A5nRGhSNSHqtDMDSFDC2sw/values/AxMr6DaVS_W1RiBGeh7vEg",
            "@type": "knora-api:LinkValue",
            "knora-api:attachedToUser": {
                "@id": "http://rdfh.ch/users/lumieres-lausanne-admin"
            },
            "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director|D knora-admin:Creator|M http://rdfh.ch/groups/0113/lumieres-lausanne-phdstudent,http://rdfh.ch/groups/0113/lumieres-lausanne-researcher,http://rdfh.ch/groups/0113/lumieres-lausanne-student|V http://rdfh.ch/groups/0113/lumieres-lausanne-user,knora-admin:KnownUser,knora-admin:UnknownUser",
            "knora-api:linkValueHasTarget": {
                "@id": "http://rdfh.ch/0113/e2haKhR4Trq_nuhEa8CAJA",
                "@type": "lumieres-lausanne:Collection",
                "knora-api:arkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/e2haKhR4Trq_nuhEa8CAJAq"
                },
                "knora-api:attachedToProject": {
                    "@id": "http://rdfh.ch/projects/0113"
                },
                "knora-api:attachedToUser": {
                    "@id": "http://rdfh.ch/users/jZhIWTXaRAG5l-9zKR1iog"
                },
                "knora-api:creationDate": {
                    "@type": "xsd:dateTimeStamp",
                    "@value": "2019-05-29T14:04:56.701073Z"
                },
                "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director,knora-admin:Creator|M http://rdfh.ch/groups/0113/lumieres-lausanne-phdstudent",
                "knora-api:userHasPermission": "CR",
                "knora-api:versionArkUrl": {
                    "@type": "xsd:anyURI",
                    "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/e2haKhR4Trq_nuhEa8CAJAq.20190529T140456701073Z"
                },
                "rdfs:label": "194"
            },
            "knora-api:userHasPermission": "CR",
            "knora-api:valueCreationDate": {
                "@type": "xsd:dateTimeStamp",
                "@value": "2019-05-29T14:09:51.601709Z"
            }
        }
    ],
    "knora-api:arkUrl": {
        "@type": "xsd:anyURI",
        "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/A5nRGhSNSHqtDMDSFDC2swg"
    },
    "knora-api:attachedToProject": {
        "@id": "http://rdfh.ch/projects/0113"
    },
    "knora-api:attachedToUser": {
        "@id": "http://rdfh.ch/users/lumieres-lausanne-admin"
    },
    "knora-api:creationDate": {
        "@type": "xsd:dateTimeStamp",
        "@value": "2019-05-29T14:09:51.601709Z"
    },
    "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director|D knora-admin:Creator|M http://rdfh.ch/groups/0113/lumieres-lausanne-phdstudent,http://rdfh.ch/groups/0113/lumieres-lausanne-researcher,http://rdfh.ch/groups/0113/lumieres-lausanne-student|V http://rdfh.ch/groups/0113/lumieres-lausanne-user,knora-admin:KnownUser,knora-admin:UnknownUser",
    "knora-api:lastModificationDate": {
        "@type": "xsd:dateTimeStamp",
        "@value": "2019-05-29T14:19:56.693713Z"
    },
    "knora-api:userHasPermission": "CR",
    "knora-api:versionArkUrl": {
        "@type": "xsd:anyURI",
        "@value": "https://ark.dasch.swiss/ark:/72163/1/0113/A5nRGhSNSHqtDMDSFDC2swg.20190529T141956693713Z"
    },
    "rdfs:label": "21",
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "knora-api": "http://api.knora.org/ontology/knora-api/v2#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "lumieres-lausanne": "http://0.0.0.0:3333/ontology/0113/lumieres-lausanne/v2#"
    }
}

As explained, for example, the first Collection with IRI http://rdfh.ch/0113/xYkKg_GfQ5az0FOqS1iOwA cannot be seen by a lumieres-lausanne-phdstudent user:

{
    "@id": "http://rdfh.ch/0113/xYkKg_GfQ5az0FOqS1iOwA",
[...]
    "knora-api:hasPermissions": "CR http://rdfh.ch/groups/0113/lumieres-lausanne-administrator,http://rdfh.ch/groups/0113/lumieres-lausanne-director,knora-admin:Creator"
[...]
}

The text was updated successfully, but these errors were encountered:

benjamingeer · 2019-06-05T16:09:15Z

@tobiasschweizer Do you think this is a bug? Or is it correct behaviour?

tobiasschweizer · 2019-06-06T06:31:33Z

I am not sure I understand correctly. Could I see the complete response?

gfoo · 2019-06-06T07:12:33Z

Sorry, I'm not very clear... So, when I run the cited gravsearch query, I get that response:

{
    "@id": "http://rdfh.ch/0000/forbiddenResource",
    "@type": "knora-api:ForbiddenResource",
    "knora-api:arkUrl": {
        "@type": "xsd:anyURI",
        "@value": "https://ark.dasch.swiss/ark:/72163/1/0000/forbiddenResourceV"
    },
    "knora-api:attachedToProject": {
        "@id": "http://www.knora.org/ontology/knora-admin#SystemProject"
    },
    "knora-api:attachedToUser": {
        "@id": "http://rdfh.ch/users/root"
    },
    "knora-api:creationDate": {
        "@type": "xsd:dateTimeStamp",
        "@value": "2017-10-06T11:05:37Z"
    },
    "knora-api:hasPermissions": "CR knora-admin:Creator|M knora-admin:ProjectMember|V knora-admin:KnownUser|V knora-admin:UnknownUser",
    "knora-api:userHasPermission": "V",
    "knora-api:versionArkUrl": {
        "@type": "xsd:anyURI",
        "@value": "https://ark.dasch.swiss/ark:/72163/1/0000/forbiddenResourceV.20171006T110537Z"
    },
    "rdfs:label": "This resource is a proxy for a resource you are not allowed to see (may depend on the context: query path)",
    "@context": {
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "knora-api": "http://api.knora.org/ontology/knora-api/v2#"
    }
}

While, if I use the v2/resource endpoint with the same user I get the cited response (I called that the normal response).

I think the problem comes from the user rights, this user does not have access to the linked Collection resources, but I don't ask for it, I just ask for the the linked properties values (isInCollection) giving the IRI of related collections. Is that more clear?

tobiasschweizer · 2019-06-06T07:15:31Z

The rule is: if the user does not have sufficient permission on anything (linking value or referred resource) in the WHERE clause, the forbidden resource is returned.

gfoo · 2019-06-06T07:25:15Z

1/ so it's not the same rule as with v2/resources?

2/ I cannot get the isInCollection values using gravsearch while this user has view access on this property?

And the only solution there is to remove this property of the gravsearch query?

tobiasschweizer · 2019-06-06T07:41:04Z

no, it's not the same rule.
you need sufficient permissions on the link value and the referred resource.

I think the problem comes from the user rights, this user does not have access to the linked Collection resources

If the user can see the link value but not the referred resource, the forbidden resource is returned.

benjamingeer · 2019-06-06T07:43:06Z

no, it's not the same rule.

But I think Gilles is saying that when he uses /v2/resources, he gets a different result: he doesn't get ForbiddenResource. Is that right?

tobiasschweizer · 2019-06-06T07:44:12Z

But I think Gilles is saying that when he uses /v2/resources, he gets a different result: he doesn't get ForbiddenResource. Is that right?

/v2/resources would just hide the values that you cannot see, but not suppress the whole resource

gfoo · 2019-06-06T07:44:55Z

no, it's not the same rule.

But I think Gilles is saying that when he uses /v2/resources, he gets a different result: he doesn't get ForbiddenResource. Is that right?

yes, exactly.

benjamingeer · 2019-06-06T07:45:30Z

/v2/resources would just hide the values that you cannot see, but not suppress the whole resource

Right, so the two routes don't apply the same rule. Hence my question: is this correct, and if so, do you remember why we decided to do it this way?

tobiasschweizer · 2019-06-06T07:47:05Z

I think it's correct. We do not want the user to know that a specific resource links to another one when he does not have the sufficient permissions on the link value or the referred resource. If the resource was returned without the link value / the nested resource, the user could still infer the such a relation exists.

tobiasschweizer · 2019-06-06T07:48:31Z

just think of the dating website metaphor :-)

benjamingeer · 2019-06-06T07:51:16Z

So the logic is:

We hide relations that you don't have permission to see. If you use Gravsearch, you're saying, "Show me the resources that have this relation." To hide the relation, we have to hide the resource. But if you use /v2/resources, you're not asking about a relation, so we can hide the relation without hiding the whole resource.

Let's document it.

tobiasschweizer · 2019-06-06T07:53:12Z

yes

benjamingeer · 2019-06-06T08:12:25Z

But I could do something like this:

CONSTRUCT {
    ?johnSmith knora-api:isMainResource true .
} WHERE {
    BIND(<http://rdfh.ch/john-smith> as ?johnSmith)

    ?johnSmith example:isDatingPerson ?otherPerson .
    
    FILTER NOT EXISTS {
        ?johnSmith example:isSpouseOf ?otherPerson .
    }
}

If I got ForbiddenResource, I would know that the relation existed.

tobiasschweizer · 2019-06-06T08:13:01Z

we do not hide that such a relation exists

benjamingeer · 2019-06-06T08:13:38Z

we do not hide that such a relation exists

So why return ForbiddenResource?

tobiasschweizer · 2019-06-06T08:14:43Z

we do not hide that such a relation exists but still do not tell to what resource it applies

tobiasschweizer · 2019-06-06T08:15:30Z

ideally, the resource would be suppressed, but that would make paging difficult

benjamingeer · 2019-06-06T08:15:51Z

we do not hide that such a relation exists but still do not tell to what resource it applies

So why not have the same behaviour as in /v2/resources: return <http://rdfh.ch/john-smith> in the results, but without the link to the other person?

tobiasschweizer · 2019-06-06T08:17:29Z

I remember we agreed that the client must have sufficient permissions on everything present in the restrictions, otherwise forbidden resource is returned

that could surely be changed in the processing logic

tobiasschweizer · 2019-06-06T08:22:13Z

now I remember: we decided that Knora does not have to provide the same level of security as a dating website service

benjamingeer · 2019-06-06T08:24:39Z

I think the problem is ForbiddenResource. If you return ForbiddenResource, it means your search criteria matched. You could even do:

CONSTRUCT {
    ?johnSmith knora-api:isMainResource true .
} WHERE {
    BIND(<http://rdfh.ch/john-smith> as ?johnSmith)
    ?johnSmith example:isDatingPerson <http://rdfh.ch/jane-jones>.
}

Then if you got ForbiddenResource, you would know that the relation exists and which resource the link points to, even if you don't have permission to see any of them.

Could we make it so that if your search returns less than one page of results, and they're all forbidden, we return 0 results to the client, instead of returning ForbiddenResource?

tobiasschweizer · 2019-06-06T08:26:20Z

I am happy to think about this in the future but right now I am very busy finishing the BEOL project and documenting everything.

benjamingeer · 2019-06-06T08:26:30Z

OK.

gfoo · 2019-06-06T08:53:21Z

A logical way for us (with @mrivoal and @loicjaouen) could be to return in any cases the link, and when the link refers to a ForbiddenResource, the IRI of the referred resource could be replaced by the ForbiddenResource's IRI. The information given is that there is a link to a forbidden resource that is correct and consistent for us because the user has enough rights to view the link.

gfoo · 2019-07-30T14:39:22Z

I am happy to think about this in the future but right now I am very busy finishing the BEOL project and documenting everything.

@tobiasschweizer Could you give me your opinion about that issue?
Do you think that gravsearch could be more flexible like @benjamingeer's proposition or like our proposition in the previous comment?

tobiasschweizer · 2019-08-05T07:34:06Z

@gfoo Yes, of course it could be made more flexible!

org.knora.webapi.responders.v2.search.MainQueryResultProcessor#getMainQueryResultsWithFullGraphPattern currently behaves as follows:

https://github.com/dhlab-basel/Knora/blob/cf8f23d4681caceb86641969d72c252bcb3f838a/webapi/src/main/scala/org/knora/webapi/responders/v2/search/MainQueryResultProcessor.scala#L205-L207

I think org.knora.webapi.responders.v2.search.MainQueryResultProcessor#getMainQueryResultsWithFullGraphPattern could be changed so it behaves as suggested in #1344 (comment). But the logic would be more complicated. Right now, it just checks for all the value objects and dependent resources after performing permissions checking:

https://github.com/dhlab-basel/Knora/blob/cf8f23d4681caceb86641969d72c252bcb3f838a/webapi/src/main/scala/org/knora/webapi/responders/v2/search/MainQueryResultProcessor.scala#L226-L227

Permission checking removes value objects or dependent resources the user has insufficient permissions to see:

https://github.com/dhlab-basel/Knora/blob/cf8f23d4681caceb86641969d72c252bcb3f838a/webapi/src/main/scala/org/knora/webapi/responders/v2/search/MainQueryResultProcessor.scala#L265-L267

@benjamingeer suggested in #1344 (comment)

Could we make it so that if your search returns less than one page of results, and they're all forbidden, we return 0 results to the client, instead of returning ForbiddenResource?

I think this would have to be done after org.knora.webapi.responders.v2.search.MainQueryResultProcessor#getMainQueryResultsWithFullGraphPattern.

So we need to agree on how we want Gravsearch to behave and who would implement that change. Also I think this should include writing unit tests for org.knora.webapi.responders.v2.search.MainQueryResultProcessor.

mrivoal · 2019-09-05T10:22:12Z

I would like to discuss this point again and insist on this part:
#1344 (comment)

From our point of view, and given the granularity allowed by that the current permissions' schema, the current behaviour of Gravsearch may be too simplistic. It raises troubles for the development of Lumières.Lausanne application.

Given the above ontology, I think we should definitely be able to display a list of Person in a project-specific GUI, even though the users have no permissions to access the linked Collection, but only the link property.

If the resource was returned without the link value / the nested resource, the user could still infer the such a relation exists.

I think we could/should live with that. As long as you don't know what is the target resource of the link property, I don't think it is a problem.

benjamingeer · 2019-09-05T11:04:35Z

Given the above ontology, I think we should definitely be able to display a list of Person in a project-specific GUI, even though the users have no permissions to access the linked Collection, but only the link property.

I believe that this is already the case, as long as your query does not ask for the linked Collection to be returned in the query result. If all you want is a list of Person, why are you querying the link?

benjamingeer · 2019-09-05T11:15:00Z

As long as you don't know what is the target resource of the link property, I don't think it is a problem.

I think it would be difficult to guarantee this in any case. You could, for example, specify the target resource in a BIND in the query, as I said above: #1344 (comment)

benjamingeer · 2019-09-05T11:16:29Z

I have also been wondering for a long time whether we could eliminate ForbiddenResource. I believe the reason for it is to indicate whether another page of results is available. But in that case, couldn't we just return a boolean moreResultsAvailable?

subotic · 2019-09-05T11:27:49Z

Wasn't paging the reason for ForbiddenResource?

benjamingeer · 2019-09-05T11:46:04Z

Wasn't paging the reason for ForbiddenResource?

Yes, the idea is that all pages except the last one have a fixed size. If you get a page that's smaller than the fixed size, you know it's the last page. ForbiddenResource is a kind of padding for pages before the last one. But I don't understand why we couldn't just return a boolean (nextPageAvailable) instead.

tobiasschweizer · 2019-09-05T11:51:04Z

But I don't understand why we couldn't just return a boolean (nextPageAvailable) instead.

Could there be empty pages then?

benjamingeer · 2019-09-05T12:06:53Z

Could there be empty pages then?

Yes, I think that would make sense.

An alternative would be that Knora could automatically query the next page until it got a non-empty one. But that could take a long time if there were a lot of results that the user didn't have permission to see. Maybe better to let the client do it; then the user can see what's going on, and maybe change their query.

tobiasschweizer · 2019-09-05T12:12:23Z

so that means this is something I should keep in mind when writing the search endpoint in knora-api-lib-js

gfoo · 2019-09-05T14:16:56Z

So, could we back to my initial question? :)

Let say, we have this ontology Person --hasNote--> Note.
How I think I have to get data of this part of the model:

I use Gravsearch to query all Person resources with their Notes (so using the hasNote link),
BUT if the current user has not enough permission to view all Notes, a ForbiddenResource is returned in place of Person

If you think that this is a normal way to manage permissions, so the only solution to get data using gravsearch will be:

query all Person resources
for each Person query all its Notes using incoming hasNote link (will return ForbiddenResource for unviewable Notes)
And that, for all property links possibly related to not permitted resources

It really depends on how

the user interface is (for example a 'Note' of a Person could be shown only if the user clicks on a button, and then do the Notes' query)
the ontology is deep to access the related resources (see Performance consideration on API usage #1303 Compounded Resources #785)

Maybe we should redesign our web app to consume less data at one time, that is the case of modern UX design, all is reactive now!

But why to use systematically Gravsearch? Because it is flexible, orderable, constraintable, response size optimizable. THE missing feature from my point of view: do no return ForbiddenResource #1016

tobiasschweizer · 2019-09-05T15:10:11Z

Because it is flexible, orderable, constraintable, response size optimizable. THE missing feature from my point of view: do no return ForbiddenResource

Ok, let's consider getting rid of ForbiddenResource

gfoo · 2019-09-05T15:20:20Z

Ok, let's consider getting rid of ForbiddenResource

for what I remember it is not so possible right now mainly because the permissions constraints are not in the sparql query which provides the pages?... Maybe it is not true anymore.

But it could be implemented in knora-api-lib-js with a caching sytem.

benjamingeer · 2019-09-05T15:23:37Z

for what I remember it is not so possible right now mainly because the permissions constraints are not in the sparql query which provides the pages?... Maybe it is not true anymore.

It's still true, because the permissions constraints can't be implemented in SPARQL.

We can get rid of ForbiddenResource by returning shortened pages and a boolean as I suggested above, but that won't affect the permissions problem you're having. It's a separate issue.

benjamingeer · 2019-09-05T15:44:35Z

But it could be implemented in knora-api-lib-js with a caching sytem.

Permissions have to be implemented in the Knora, otherwise any client could ignore them.

mrivoal · 2019-09-06T07:31:38Z

If we go back to the initial issue,

BUT if the current user has not enough permission to view all Notes, a ForbiddenResource is returned in place of Person

Do you think this is the correct behaviour? If so (I am not yet quite convinced), then we should find a workaround for Lumières.Lausanne.
But if you think that this should/could be adapted, like suggested in #1344 (comment), what would it take ?

gfoo · 2019-09-20T08:53:49Z

For all previous use cases cited above, I think I can find other ways to access data without right permissions errors:

by asking for Note related to a Person instead of all Person with their Notes
by using v2/resources endpoint to get all the hasNote property IRI values (I have to know this value to remove a Note for example)

But I have a last use case that I don't know how to fix if the current user has not enough rights to access to all Note resources:

|Text| <--hasBio-- (Person) --hasNote--> (Note) --hasContent--> |Text|

Find all Persons matching a specified text in hasBio or/and hasContent properties.

This is something that you will have to face in the extended search of Kuirl?

benjamingeer · 2019-10-25T08:09:11Z

Moving to #1494.

gfoo added API/V2 Gravsearch labels Jun 5, 2019

benjamingeer assigned tobiasschweizer Jun 5, 2019

gfoo added this to the 2019-10 milestone Sep 25, 2019

benjamingeer closed this as completed Oct 25, 2019

benjamingeer mentioned this issue Nov 20, 2019

fix(gravsearch): Unify permissions handling with full resource request #1521

Merged

benjamingeer modified the milestones: 2019-10, 2019-12 Dec 5, 2019

benjamingeer added the breaking/api label Dec 5, 2019

Gravsearch ForbiddenResource result and permissions of linked resources #1344

Gravsearch ForbiddenResource result and permissions of linked resources #1344

Comments

gfoo commented Jun 5, 2019 • edited Loading

benjamingeer commented Jun 5, 2019

tobiasschweizer commented Jun 6, 2019

gfoo commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

gfoo commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

gfoo commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019 • edited Loading

tobiasschweizer commented Jun 6, 2019

benjamingeer commented Jun 6, 2019

gfoo commented Jun 6, 2019 • edited Loading

gfoo commented Jul 30, 2019

tobiasschweizer commented Aug 5, 2019

mrivoal commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

subotic commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

tobiasschweizer commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

tobiasschweizer commented Sep 5, 2019

gfoo commented Sep 5, 2019

tobiasschweizer commented Sep 5, 2019

gfoo commented Sep 5, 2019 • edited Loading

benjamingeer commented Sep 5, 2019

benjamingeer commented Sep 5, 2019

mrivoal commented Sep 6, 2019

gfoo commented Sep 20, 2019

benjamingeer commented Oct 25, 2019

gfoo commented Jun 5, 2019 •

edited

Loading

benjamingeer commented Jun 6, 2019 •

edited

Loading

gfoo commented Jun 6, 2019 •

edited

Loading

gfoo commented Sep 5, 2019 •

edited

Loading