A restriction on api_username appears to have been enforced, causing issues for applications using a virtual username to represent unsigned-in users. Justin_Powell experienced this issue on October 25, 2020, and mitigated it by creating a user with the previously virtual username. However, blake is unsure if a recent change caused this behavior, suggesting it may have always worked this way. blake notes that a recent change 23 days prior does not apply to this situation and that using a non-existent user would still raise an error.
As an alternative, riking suggests making unauthenticated requests from the backend for public sites to get the anonymous view. blake also proposes that the revoke api keys days site setting may have caused the issue due to the non-existent user.
It is recommended to create a dummy user or update the API key to have read-only access to resolve the issue.
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
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.
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.
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.
