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 autthenticated requests with user name in path broken #1038

Closed
IzStriker opened this issue Mar 30, 2024 · 13 comments
Closed

API autthenticated requests with user name in path broken #1038

IzStriker opened this issue Mar 30, 2024 · 13 comments
Assignees
Labels
bug Something isn't working

Comments

@IzStriker
Copy link

I don’t know if this is the correct place to post this issue, but there seems to be an issue with the https://wakatime.com/api/v1/users/:user/stats/:range endpoint when making authenticated requests. I have a Discord bot that ranks server members based on the amount of programming they’ve done in the previous week/month, etc. The bot makes authenticated requests to https://wakatime.com/api/v1/users/:user/stats/:range, but it seems this endpoint has broken in the past few months as it always returns:

{
    "error": "Time range not matching user's public stats range."
}

When I change :user to be current in the URL, authenticated requests work. I would make this change in the code, but I use the unique URLs for each user for caching purposes. This definitely worked previously, as I was using this endpoint for a while before it broke.

@IzStriker IzStriker added the bug Something isn't working label Mar 30, 2024
@alanhamlett alanhamlett self-assigned this Mar 31, 2024
@alanhamlett
Copy link
Member

That means you're not correctly authenticated as the user that you're requesting stats for. You can check the user you're authenticated as by making the same request to this url:

https://api.wakatime.com/api/v1/users/current

@alanhamlett
Copy link
Member

When I change :user to be current in the URL, authenticated requests work.

That means you're requesting stats for a user different to the authenticated user? Check that from the stats response user_id attribute to make sure it's the same as you're expecting. Meaning, it should be the same as the :user part from the url, after you switch :user out for current.

@IzStriker
Copy link
Author

IzStriker commented Mar 31, 2024

When I was investigating the issue orignially, I only tested with a single user, my user. Also this broke one day without me making any code changes after it having worked for a year or so. If I was authenticated to wrong user shouldn't I receive a 403 I instead of a 400.

I did as you suggested and checked the user I was authenticated as, shows IzStriker.

Interestingly, only making authenticated requests.
https://api.wakatime.com/api/v1/users/IzStriker works.

https://api.wakatime.com/api/v1/users/IzStriker/stats works, but doesn't return the fields that are only available when authenticated (e.g. projects).

https://api.wakatime.com/api/v1/users/IzStriker/stats/last_7_days returns a 400 as described in the original post.

https://api.wakatime.com/api/v1/users/current/stats works, but doesn't return the fields that are only available when authenticated (e.g. projects).

Note: The scope for the access token is "email,read_stats".

@alanhamlett
Copy link
Member

alanhamlett commented Mar 31, 2024

What about https://api.wakatime.com/api/v1/users/current? My guess is you've been using the public endpoints this whole time without authentication. These both work without authentication because they're publicly accessible:

  • https://api.wakatime.com/api/v1/users/IzStriker → 200
  • https://api.wakatime.com/api/v1/users/IzStriker/stats → 200
  • https://api.wakatime.com/api/v1/users/IzStriker/stats/all_time → 200

But the change we made recently was returning 400 instead of redirecting to the public view when you request any non-public range of stats for a user while not authenticated as that user:

  • https://api.wakatime.com/api/v1/users/current → 401
  • https://api.wakatime.com/api/v1/users/IzStriker/stats/last_7_days → 400 (previously this would redirect)

@djpiper28
Copy link

It is possible that is was redirecting to the public endpoints, however due to rolling logs I cannot see if that is the case with iStriker and I's software.

@alanhamlett
Copy link
Member

We changed the api to show an error when requesting an invalid range instead of redirecting about 3 months ago, to prevent api consumers accidentally using a response for X range when they requested Y range.

@IzStriker
Copy link
Author

What about https://api.wakatime.com/api/v1/users/current? My guess is you've been using the public endpoints this whole time without authentication.

This returns the expected data when I make the request with the access token and doesn't works without. It seems unlikely that I was using the public endpoints the whole time because I was accessing the projects field and using the different time ranges which aren't available from the public endpoint.

To just to elimiate any confusion this is the request I'm doing.

curl --location 'https://api.wakatime.com/api/v1/users/IzStriker/stats/last_7_days' \
--header 'Authorization: Bearer <redacted> \
--header 'Cookie: csrftoken=<redacted>; session=<redacted>'

If you're familar with dotnet here is the code that broke 3 (or so) months ago https://github.com/IzStriker/WakaBot/blob/509eed9b8e837fb1bcb7d15da20a49b2f60c1046/WakaBot.Core/WakaTime/WakaTime.cs#L100C9-L100C116
https://github.com/IzStriker/WakaBot/blob/master/WakaBot.Core/Extensions/HttpClientExtension.cs

@djpiper28
Copy link

What I'll do when I get I back from the pub is make a code change to use /current and see if that works.

@IzStriker
Copy link
Author

Current works, it just will break caching because all users will use the same url.

@alanhamlett alanhamlett reopened this Apr 1, 2024
@alanhamlett
Copy link
Member

Looks like there's a bug on our end, I'll get it fixed soon.

@alanhamlett
Copy link
Member

alanhamlett commented Apr 1, 2024

It's fixed. Turns out you were doing everything correctly, but we broke parsing the username from api urls, only when checking OAuth scopes. It worked with current and when using the user's id but not username.

@alanhamlett
Copy link
Member

alanhamlett commented Apr 1, 2024

Also related but not required, usernames change so it's better to use user.id in the api url. It works with your caching, and doesn't risk a 404 if the user changes their username.

@IzStriker
Copy link
Author

IzStriker commented Apr 1, 2024

Great, thanks for your time. I'll change it to use user id.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants