Newly enforced api_username restriction?

For our application, we use a global API key to be used with all users. We were using a virtual username (non-existent user) anonymous to represent the context when a user was not signed in. This worked for the last 3+ years until 10/25/2020 @ 12:39am CT.

I mitigated this today by creating a user with that username. Was a restriction rolled out this weekend? Update to API?

This broke the ability to view comments for all public users, so an answer is much appreciated.

Thanks,

Justin

Here’s the error…

I’m not aware of a recent change that would have changed this behavior. I was under the impression it always worked like this (displaying an error if the user cannot be found). This is the code that checks if it can read the username from the api credentials

And the user below will be nil because it doesn’t exist, which will raise the error message above on line 131.

A recent change was made 23 days ago, but it doesn’t apply to your situation and returns a different error message anyways.

Just to double check, I configured my local discourse to use this commit from over a year ago and I get the same error when using a non-existent user.

One good thing that comes from this is that we have api scopes now, so if the users only need read access, you can update that api key so that it is no longer an all access key.

1 Like

If it’s a public site, then you should be able to make these requests from your backend with no authentication at all to get the anonymous view. If rate limits become a problem, then yes you’ll need to use an actual dummy user.

1 Like

One other thing I just thought about is the revoke api keys days site setting. Because that user doesn’t exist, we never update the last used date for that key and I bet the key was auto revoked? I’m still not sure how you would have been able to make valid request in the first place though.