discord-api-docs
discord-api-docs copied to clipboard
discord
`premium_type` is included in partial user objects without OAuth2
Description
The 2023-10_social_proofing_message_nitro_badge experiment introduced Nitro badges next to usernames in chat. For this feature to function, premium_type was added to the partial user object. The field is already documented, but the field used to require the identify scope using OAuth2. Moreover, the field is absent in some contexts where partial user objects exist, such as gateway events containing member objects. As such, the exposure on GET /users/<user_id> and GET /channels/<channel_id>/messages might be unintentional and could lead to the collection of premium statuses that Discord historically has kept private from applications without proper OAuth2 scopes.
However, if this API change is considered intentional, it would be helpful for third-party developers to know whether to incorporate it in their code and libraries since it's unclear whether the field will remain supported in this context.
Steps to Reproduce
curl -L 'https://discord.com/api/v10/users/21414249976823808' -H 'Authorization: Bot <token>'
Expected Behavior
The premium_type field should not be exposed to application users without an OAuth2 scope unless considered an intentional and safe-to-implement API change.
Current Behavior
The premium_type field is exposed in partial user objects in the API, outside the GET /users/@me route using OAuth2.
Screenshots/Videos
No response
Client and System Information
N/A — All API versions are affected.
Thank you for flagging this! I've raised it with the team and a fix should be going out next week
The behavior will return to what it was before the 2023-10_social_proofing_message_nitro_badge experiment, which I believe means it'll be back behind the identity scope.
but why does it need to be private? i just used it for a user info slash command is it causing any harm? that way i found out that clyde had nitro and any other bot user not or other interesting stuff
premium_type field gone from GET /users/{user.id} route. Please bring it back
can you at least explain why it needs to be private? there are allot of dislikes arround
This is private information about the user that should not be exposed publicly. As such, accessing it requires the IDENTITY oauth scope.
This is private information about the user that should not be exposed publicly. As such, accessing it requires the
IDENTITYoauth scope.
There is no reason to make it private, other than to inconvenience developers, aswell as silently removing it without actually mentioning it rather having to look for a git issue reporting the "issue".
Now i have to look for another method to determine a discord's account suspicious level when used to join game servers. As external service oauth is not possible without first kicking the user and kindly asking them to log in, which is not good UX.
There is no reason to make it private, other than to inconvenience developers, aswell as silently removing it without actually mentioning it rather having to look for a git issue reporting the "issue".
It was not mentioned to be public nor was it part of the documented API without the scope. These comments are not justifiable: you relied on undocumented and unintentional behaviour.
There is no reason to make it private, other than to inconvenience developers, aswell as silently removing it without actually mentioning it rather having to look for a git issue reporting the "issue".
It was not mentioned to be public nor was it part of the documented API without the scope. These comments are not justifiable: you relied on undocumented and unintentional behaviour.
Perhaps discord should focus on making the api documentation more clear then, and then silently removing parameters for no reason
"GET /users/{user.id}" Returns a User object for a given user ID.
Where everything in the User object is requiring an oauth2 scope? Yet it quite clearly returns common data. So how am i supposed to know that premium_type is this "special case" when it has been included for a while?
And once again there is no reason to make it private, these comments are very justifiable.
We are not adding this back without an oauth2 scope at this time.
I am locking this discussion, as no further conversation here is productive.
The comment on how the documentation can be improved has been noted. PRs are welcome, if you'd like to help us re-format this data to clarify.
