API token authentication fails, if "Accept" header isn't explicitly set to JSON

Bug
1

Just noticed this tiny issue while experimenting with the API. It’s no deal breaker, but certainly confusing, especially when trying this first time.

Sending the following request will fail with HTTP 401 Unauthorized (curl submits Accept: */*):

curl -v -H "Authorization: Bearer <valid token>" https://vikunja-server/api/v1/projects"

This can be fixed by adding the Accept header field with an explicit JSON request:

curl -v -H "Accept: application/json" -H "Authorization: Bearer <valid token>" https://vikunja-server/api/v1/projects"

I think either request should actually pass, since the token actually is valid (so the given error message is wrong) and considering the fact the error message is submitted as JSON anyway.

(Edit: This happens with the current unstable docker image pair.)

2

This works fine for me:

curl 'http://localhost:3456/api/v1/projects' -H "Authorization: Bearer $BEARER"

which version are you using?

3 
curl 8.0.1 (Windows) libcurl/8.0.1 Schannel WinIDN

But now that you mention it works for you, I’ve tried it with the public demo instance and it works there, too. So this seems to be some random quirk caused by the proxying Apache I’m using in front of the Docker host. Will try to look more into this.

4

Just one more note (should really go to bed!:wink:), because this might be related:

If I query any random non-existing API endpoint, like let’s say /api/v1/randomgarbage I get HTTP 401, too (even on the demo server), while I’d actually expect HTTP 404.

5

You get the 404 when you access the endpoint with a valid api token. It is unexpected but since the middleware just check every incoming request it makes sense from an engineering perspective (ux is another story here)

6

Maybe I misunderstood you and you meant that it’s simply 401, since no route accepted the request (typically caused by a failing API Token).

I’ve created an API Token on the demo server (ID 12 that’s still there) and it is valid.

Requesting /api/v1/notifications returns null (as expected).
Requesting /api/v1/notificationsx returns HTTP 401.

7

Ahh if you’re using the api tokens and not a jwt token you’ll get a 401 for routes which you’re not allowed to access since the tokens are scoped. The way the scoping works is it checks if you’re allowed to use the current route and returns a 401 if it’s not in the list. It does not check if the route exist because that happens after the token middleware.

8

Ah, okay, so what I suspected. Okay, everything solved then.