How to deal with forbidden resources and values consistently?

I’m trying to figure out the best way to make Knora API v2 deal consistently with resources and values that the user doesn’t have permission to see.

Currently, Gravsearch returns HTTP 200 and a ForbiddenResource for each resource that you don’t have permission to see. But everything else in API v2 returns either:

  • NotFoundException (HTTP 404): “One or more requested resources were not found (maybe you do not have permission to see them, or they are marked as deleted)”
  • ForbiddenException (HTTP 403)

If you request a resource containing values that you don’t have permission to see, those values are simply invisible.

If you request a resource containing a link to a resource that you don’t have permission to see, you get a link value containing only the target resource’s IRI, and no other information about the target resource.

This all seems inconsistent.

The idea of using HTTP 404, and hiding values, dates back to when we were trying to keep the user from finding out about the existence of things they don’t have permission to see. We decided to abandon that approach a few months ago (see Change in the way Gravsearch results are filtered according to permissions):

the purpose of permissions on resources and values is to respect copyright, not to protect privacy.

Therefore, issue #1543 says:

If you request two resources from /v2/resources, and you only have permission to see one of them, you should get one resource and one ForbiddenResource.

Also, #1521 changed Gravsearch so that if you don’t have permission to see a dependent resource, you get a link value with just the target resource’s IRI. This is also what /v2/resources does. It would be more consistent to use ForbiddenResource for the dependent resource, too.

I started work on this in #1615. Thinking about it some more, I wonder if it would also make sense to create a ForbiddenValue and return it for each value that the user doesn’t have permission to see. Then the user would always know that there’s something there that they don’t have access to, whether it’s a resource or a value. Then they could ask someone for access to it.

Does anyone have an opinion about this?

ideally, I would prefer not seeing at all Resources or Values that I don’t have the rights to see, not seeing the links to resources or values.

given the data:

  • when browsing the resource Mactintosh
    • I would rather not see ForbiddenValue or even hasCode if I don’t have the rights to see the Aladdin or hasCode
    • I would rather not see ForbiddenResource when I have the right to see Job, I would prefer to see only one hasMember
  • when asking for the exhaustive list of persons, I would rather get only Raskin and a match count of one and no Forbidden if I don’t have rights to see Job

But that’s just personnel preferences, I don’t see obvious case advocating it.

Thanks @loic.jaouen. Considering that (for now) we need ForbiddenResource in Gravsearch results, do you think it’s OK that we use ForbiddenResource only for Gravsearch, while the rest of the API behaves differently?

We could certainly not return a link value if you don’t have permission to see the linked resource, that would be only a small change.

Another option I just remembered:

We could get rid of ForbiddenResource for Gravsearch too, if Gravsearch instead returned something like lastPage: true/false with each page, so you would know whether you could request another page of results.

do you think it’s OK that we use ForbiddenResource only for Gravsearch, while the rest of the API behaves differently?

i think it is completely fine

… but I am afraid of:

  • not getting the full implications of such statements
  • my opinion not being representative

We could get rid of ForbiddenResource for Gravsearch too, if Gravsearch instead returned something like lastPage: true/false with each page

I realise now that the other thread I started is linked https://discuss.dasch.swiss/t/post-request-match-count/155

The more I think about it, the more I think the other option makes sense: get rid of ForbiddenResource completely. The only reason it’s there is to communicate something about paging, which we could communicate in a different way.

2 Likes

I’ve done an implementation in PR 1615 to remove ForbiddenResource. I think this makes things more consistent and simpler while keeping most of the existing behaviour.

2 Likes