Using user token while executing fetch_users throws an HTTP error

[bsalha1]

Summary

If you use a user token (as opposed to a bot token), you cannot get the non-cached users from a server. An HTTP error is thrown, meaning that it's not readily the discord.py API's fault, but the discord gateway or the http server is blocking the request. I believe there must be a way for a user token to grab non-cached users as it does it all the time in the actual app, but likely through Websockets rather than through HTTP sockets, which is why the API throws an error. This feature also doesn't work in discord.NET, JDA or discord.js.

Reproduction Steps

Log into user token, fetch users from each guild
client = discord.Client()
@client.event
async def on_ready():
for guild in client.guilds:
async for member in guild.fetch_users():
print(member.name)

client.run('<a user token>', bot=False)

Expected Results

User1
User2
User3
...

Actual Results

Ignoring exception in on_ready
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/discord/client.py", line 312, in _run_event
await coro(*args, **kwargs)
File "/root/Documents/python/adBot/start.py", line 51, in on_ready
async for member in guild.fetch_members():
File "/usr/local/lib/python3.7/dist-packages/discord/iterators.py", line 86, in __anext__
msg = await self.next()
File "/usr/local/lib/python3.7/dist-packages/discord/iterators.py", line 607, in next
await self.fill_members()
File "/usr/local/lib/python3.7/dist-packages/discord/iterators.py", line 629, in fill_members
data = await self.get_members(self.guild.id, self.retrieve, after)
File "/usr/local/lib/python3.7/dist-packages/discord/http.py", line 221, in request
raise Forbidden(r, data)
discord.errors.Forbidden: 403 FORBIDDEN (error code: 50001): Missing Access

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

System Information

• Python v3.7.5-final
• discord.py v1.3.2-final
• aiohttp v3.6.2
• websockets v8.1
• system info: Linux 5.3.0-kali3-amd64 Fix issue with author changing type #1 SMP Debian 5.3.15-1kali1 (2019-12-09)

[apple502j]

There is no Guild.fetch_users. Also userbots are against ToS.

[Vexs]

Selfbots have long been supported by this library, but a recent change on discord's end to actually start filtering clients has broken this functionality. Bypassing this filter is likely fairly easy, it's probably just user-agent-checking, perhaps some checks on the x-super-agent headers etc, basic behavior look-ats.
However, this brings up the problem: is it the library's policy to actively start putting effort into bypassing this? Previously selfbot support was either largely legacy code or was function identical to bots. But now it seems we'd need a different adapter. Another consideration is that the user-agent checking and the like could update slightly frequently on discord's end, requiring active maintenance and acknowledgement that effort is being put into bypassing.

This change on discord's end breaks a number of selfbot-only methods. If we don't fix this, should these just be removed?

Personally, given the large number of reasonable and viable uses for selfbots, as well as a personal belief that the lib shouldn't be the thing policing anyone, and that the people this was designed to be used against are still going to get around it with the bypasses described earlier, I'd like to see some methods taken to re-enable this functionality libside, or at least a more-exposed method to do so. Selfbots have a long and important history in discord, and it seems foolish to disregard them.

Also, there is a fetch_members method which is likely what he's using.

[bsalha1]

Selfbots have long been supported by this library, but a recent change on discord's end to actually start filtering clients has broken this functionality. Bypassing this filter is likely fairly easy, it's probably just user-agent-checking, perhaps some checks on the x-super-agent headers etc, basic behavior look-ats.
However, this brings up the problem: is it the library's policy to actively start putting effort into bypassing this? Previously selfbot support was either largely legacy code or was function identical to bots. But now it seems we'd need a different adapter. Another consideration is that the user-agent checking and the like could update slightly frequently on discord's end, requiring active maintenance and acknowledgement that effort is being put into bypassing.

This change on discord's end breaks a number of selfbot-only methods. If we don't fix this, should these just be removed?

Personally, given the large number of reasonable and viable uses for selfbots, as well as a personal belief that the lib shouldn't be the thing policing anyone, and that the people this was designed to be used against are still going to get around it with the bypasses described earlier, I'd like to see some methods taken to re-enable this functionality libside, or at least a more-exposed method to do so. Selfbots have a long and important history in discord, and it seems foolish to disregard them.

Also, there is a fetch_members method which is likely what he's using.

Thanks for letting me know, looks like I am going to have to make my own API.

[kavorite]

just wanted to comment on this issue to say that I also ran into this, and I think it'd be nice if there were some official means for Discord to allow people to perform ad-hoc introspection tasks on a given guild with freely available data that simply isn't exposed in the client by default -- people looking to use these applications of the library may not be seeking to actively mutate state on Discord at all, but rather simply to satisfy their curiosity, e.g. I was trying to histogram the dates members joined a certain guild over time to try to graph its growth

Discord makes no official distinction between those seeking to emulate Discord's functionality in full and those who merely wish to use a subset of it that's incapable of doing other users harm

I can't imagine it'd be that difficult to expose this API surface for extensions that ran on people's desktops without expecting them to open and authenticate an entirely new session, they simply haven't bothered, and that irks me a little bit all things considered because now there's no way to do investigations like this

it should be noted that people who can use this aren't all trying to spam people or get tool assistance in their interactions with other users

[BenjaminThijs]

Hi there, just decided I should comment here since nobody mentioned this yet.

I had the same issue, seems like some time ago discord added an option to their developer portal which allows you to enable the intent to access member information. This is off by default, thus blocking this API call.

If you go to the developer portal, then your bot account, under the bot tab you should see SERVER MEMBERS INTENT which you would need to turn on.

[Gorialis]

fetch_user has nothing to do with the server members intent - it's for toggling chunking on large guilds, since a very large bot may have many servers with thousands of users, and thus disabling the intent helps them not process data they're not interested in. A call to fetch_user is not done through the websocket, and most intents only affect the websocket, so it bypasses the need for this intent.

This is also moot when you consider that this issue pertains to userbots, which can't even have intents. Please don't necrobump old issues.