search

dasch-swiss / dsp-api

DaSCH Service Platform API
http://dasch-swiss.github.io/dsp-api/
Apache License 2.0
74 stars 18 forks source link

Gravsearch ForbiddenResource result and permissions of linked resources #1344

Closed gfoo closed 5 years ago

gfoo commented 5 years ago

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"
[...]
}
benjamingeer commented 5 years ago

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

tobiasschweizer commented 5 years ago

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

gfoo commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

1) no, it's not the same rule.

2) 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

/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 commented 5 years ago

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 commented 5 years ago

just think of the dating website metaphor :-)

benjamingeer commented 5 years ago

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 commented 5 years ago

yes

benjamingeer commented 5 years ago

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 commented 5 years ago

we do not hide that such a relation exists

benjamingeer commented 5 years ago

we do not hide that such a relation exists

So why return ForbiddenResource?

tobiasschweizer commented 5 years ago

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

tobiasschweizer commented 5 years ago

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

benjamingeer commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

benjamingeer commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

OK.

gfoo commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 https://github.com/dhlab-basel/Knora/issues/1344#issuecomment-499408660. 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 https://github.com/dhlab-basel/Knora/issues/1344#issuecomment-499398725

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 commented 5 years ago

I would like to discuss this point again and insist on this part: https://github.com/dhlab-basel/Knora/issues/1344#issuecomment-499408660

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.

Capture d’écran 2019-09-05 à 11 00 54

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 commented 5 years ago

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 commented 5 years ago

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: https://github.com/dhlab-basel/Knora/issues/1344#issuecomment-499394776

benjamingeer commented 5 years ago

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 commented 5 years ago

Wasn't paging the reason for ForbiddenResource?

benjamingeer commented 5 years ago

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 commented 5 years ago

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

Could there be empty pages then?

benjamingeer commented 5 years ago

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 commented 5 years ago

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

gfoo commented 5 years ago

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:

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

It really depends on how

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/dhlab-basel/Knora/issues/1344#issuecomment-518121204, what would it take ?

gfoo commented 5 years ago

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

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 commented 5 years ago

Moving to #1494.