mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 19:06:06 +03:00
Enhancement to Discord Social Login #3319
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @greenlighttec on GitHub (Nov 1, 2022).
Describe the feature you'd like
Right now when using Discord social login, the way DIscord works is that anyone with a Discord account (regardless if its for the server the app is created on) can login to the application that is allowing discord login. See example with internal Grafana having the same issue https://www.reddit.com/r/discordapp/comments/r7d24i/question_how_to_restrict_users_being/
I'd like the DISCORD_TEAM_ID option to be added to restrict the login to specific guilds that way forcing the users signing in to be a member of our server when trying to access the resources within Bookstack, especially as we may be hosting sensitive information.
Describe the benefits this would bring to existing BookStack users
Right now a private bookstack with Discord login is not private, anyone can login using any discord account and be granted the default permissions levels. With this new enhancement we can restrict those users to only be people who have joined the Discord server
Can the goal of this request already be achieved via other means?
Nope, slack login currently behaves the way we'd expect with a private App not allowing login from workspaces that do not have the app installed.
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
6 months to 1 year
Additional context
No response
@ssddanbrown commented on GitHub (Nov 1, 2022):
Thanks for the suggestion @greenlighttec, but I'm not looking to increase the scope of our social auth options where possible, with extra logic and handling, which it looks like this would require.
If handy with PHP, our logical theme system allows creation of custom third part auth services. You could extend the default Discord classes and apply additional required.
If needed, we could add more generic theme events around the existing social login actions, but I'd ideally want a demand for that, from someone that understands what data is required at which points, before spending time on such additions.
@greenlighttec commented on GitHub (Nov 1, 2022):
@ssddanbrown unless I misunderstood something you're using the Socialite plugin from Laravel? They added the ability to include the specific guilds as part of the scopes so I do not believe it would require any logic changes, just including the "scopes" property with the Guilds as an array to the Socialitie Driver when you hand it off for Discord?
@ssddanbrown commented on GitHub (Nov 1, 2022):
@greenlighttec From my understanding, the addition of scopes would just allow later access to such guild information, it wouldn't limit the standard oauth flow to certain guild members. Feel free to refer me to any documentation though if there is the ability to limit via scopes.
@greenlighttec commented on GitHub (Nov 1, 2022):
Ok, after I created this issue I did a ton of research on it, it's not a straight path but Discord docs say to limit OAuth logins to a specific server you should be passing the guild ID of the server you want to require membership for in as the "team_id". I found a feature request on the Laravel Github repo for allowing the use of this functionality and they closed it as completed with a link to their wiki about how to use Scopes. I lost the relevant links as I'm at work now, but I can find them tonight and come back and paste them in.
@greenlighttec commented on GitHub (Nov 3, 2022):
Ok coming back to this definitely looks like I crossed some articles in my initial research. I did find https://github.com/martinbean/socialite-discord-provider which specifically allows for Guild selection "natively" but it doesn't look like you're using this package.
@ssddanbrown commented on GitHub (Nov 3, 2022):
Thanks for providing more info.
Yeah, that package does provide a guild option but it's a parameter for the bot flow, not something for limiting user scope.
I'm going to therefore close this off since as explained above I don't want to increase scope of our auth systems.
For those looking to hack this in, you could likely do the following:
Providerclass as your base implementation.getUserByToken, to perform the additional call to get user guilds (If not already provided in theapi/users/@meresponse) and run a simple match, throwing an exception on failure.