Is plone.rest able to return 403s?

[sneridagh]

I realised that could be that the api is not able to return 403s, there are no tests and by looking at the code is difficult to say. Could be make it return it or it is not possible because something that I'm missing?

/cc @davisagli @tisto @ericof

[davisagli]

@sneridagh What is the situation where you expect it to return a 403?

IIRC, Zope does traversal and then calls verify on the user folder. It returns true or false. So we don't necessarily have the information to tell the difference between the situation where no user was authenticated vs an authenticated user who doesn't have authorization to use the traversed view.

[sneridagh]

This all revolves around detecting not valid tokens (eg. tokens from another site, when while developing changing from one backend to another). If we could do that (I thought that even Plone Classic was able to return the right status code for unauthenticated/unauthorised use cases), we could then purge all the tokens from the local config each time that a 401 is returned (as opposed while returning a legit 403 request to a forbidden request, since we won't like to do that, being a valid user).

eg. I'm a user with restricted permissions over a content object. I try to access it, then I would expect the API call returns a 403 (valid user token in that instance, but not authorized to access to that resource).

If I had an invalid user token, to access the same resource, I should have a 401 instead, same as if I were anonymous, then the system could trigger a purge of the invalid token, show appropiate error page, then redirect to the root.

[davisagli]

That sounds right as a description of what we should do. I'll need to take a closer look at whether this is something to fix in plone.rest or in Zope.