Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API returns 404 instead of 403 Forbidden if not allowed to view #2539

Open
FluidSense opened this issue Sep 25, 2020 · 2 comments
Open

API returns 404 instead of 403 Forbidden if not allowed to view #2539

FluidSense opened this issue Sep 25, 2020 · 2 comments

Comments

@FluidSense
Copy link
Contributor

Describe the bug
If a user tries to fetch an event or article from the API that they lack the permission to view, they get a 404 error.
Instead, the correct response would be 403 Forbidden ("you do not have access to this resource"). We have no reason to hide events from the API completely compared to just telling people they cannot access it.

@diegofsousa
Copy link

diegofsousa commented Oct 9, 2020

Hello @FluidSense , how are you?

I've been analyzing this issue. I was not able to simulate the scenario in "articles" in which I could generate 403, since I saw that all articles are open to GET.

In "events", I found that if the "visible" field is false, the GET in Api is returning 404. But I didn't find any access locks so I should return 403 at some point.

I would like to know what scenarios I can reproduce to find the bug :)

@FluidSense
Copy link
Contributor Author

Hey there, @diegofsousa
Thanks for looking into this!

I admit this is a weakly formulated issue, and it might also be two different cases.

Since this touches the API, you first need to set up an OIDC-client:

Setup

  • Create a new client under OpenID Connect Provider in /admin.
  • Authenticate with your selected flow and get an access token.

For events:
We sometimes create restricted events which are restricted to groups instead of rule bundles.
This is done so rarely that it is done only through /admin.

To recreate:

  • Create a new group connected to a Onlinegroup ("Onlinegrupper").
  • Create an event.
    • Add a restriction for the new group.
  • Go to frontpage: See that it is not listed.
  • Look at api/v1/events in the API: See that it is not listed.
  • Look at api/v1/event/events/{id}/: Get 404 (Remember the HTTP Header "Authorization: Bearer {access_token}")
  • Add yourself to the restricted group.
    • i.e. Add "Gruppemedlemskap".
  • Go to frontpage: See event listed.
  • Look at api/v1/events in the API: See that it is listed. (Remember the HTTP Header "Authorization: Bearer {access_token}")
  • Look at api/v1/event/events/{1}/: Get 200 and event. (Remember the HTTP Header "Authorization: Bearer {access_token}")

For articles
I have not looked a lot into this, but the behaviour should be that unpublished articles can be viewed by users in a group with permission "article: can change article". I think the current situation is that all articles are filtered by publish-date with no respect to which permissions the user have.

The steps would be:

  • Create an "unpublished" article, i.e., place the publish date in the future.
  • Look at api/v1/articles: See that it is not listed.
  • Look at api/v1/articles/{id}: Get 403 Forbidden. (Remember the HTTP Header "Authorization: Bearer {access_token}")
  • Create a new group and Onlinegroup.
  • Give the group all permissions to "articles".
  • Add yourself to the group.
  • Look at api/v1/articles/{id}: Get 200 OK. (Remember the HTTP Header "Authorization: Bearer {access_token}")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants