Discord login shows consent screen even if user has previously authorized it

[Bentroen]

When signing in with Discord, the consent screen is shown even to users who have previously authorized before:

According to Discord's OAuth2 documentation, prompt=none must be sent as a URL parameter when making the authorization request (defaults to consent which means asking for consent every single time).

However, passport-discord, the library used to handle Discord login (which is unmaintained:

Notice: I'm no longer too active with the Discord API, and only tinker around occasionally. So, if there is anybody who would like to be more active in maintaining, I'm happy to link to your fork as the new solution to use or give project permissions on this repo.

) doesn't offer support to the prompt option. Although commit nicholastay/passport-discord@3fb3435 claims to have introduced this option in v0.1.4 (for which there's no release on GitHub but only in npm), I have not managed to managed to make the option work -- even when passing it to the strategy's constructor, it doesn't seem to end up in the actual request URL.

An alternative which claims to be more maintained, @oauth-everything/passport-discord, is actually also unmaintained, and also missing the prompt option (as per oauth-everything/passport-discord#14).

An alternative with recent commits that claims to support prompt is passport-discord-auth. Fixing the problem involves replacing passport-discord with this library, and passing the prompt option in the request made here:

NoteBlockWorld/server/src/auth/strategies/discord.strategy.ts

Lines 25 to 31 in e12be94

	super({
	clientID: DISCORD_CLIENT_ID,
	clientSecret: DISCORD_CLIENT_SECRET,
	redirect_uri: `${SERVER_URL}/api/v1/auth/discord/callback`,
	scope: ['identify', 'email'],
	state: false,
	});

(It really sucks that there's no robust option that seems to be the to-go choice... offering Discord auth in Express apps isn't that uncommon, is it? 😕)

[tomast1337]

All these dependencies don't seem to have a large codebase. Maybe we can implement our own

[Bentroen]

I think that's the best strategy, yeah. Otherwise we could find ourselves in the same situation as another one of these goes unmaintained

[tomast1337]

Soon I'll be sending a pr with an implantation for it.
I don't think it will be hard to maintain our own versions. We are using an unmaintained for 6 years implementation, and it is not broken , so hopefully ours will last as long.