Select email address when registering via social account authentication #1949

Closed
opened 2026-02-05 02:17:20 +03:00 by OVERLORD · 5 comments
Owner

Originally created by @ivantomica on GitHub (Nov 19, 2020).

Describe the feature you'd like
When GIthub based authentication is enabled, it would be nice if user were able to select the email address used for creating Bookstack account.

Current behaviour is that with Github driver, primary account email is selected.

Describe the benefits this feature would bring to BookStack users

Many folks have multiple email addresses on their Github profiles. Some of them being provided by the company they work for. This would allow them to specify which address is used for which instance.

Originally created by @ivantomica on GitHub (Nov 19, 2020). **Describe the feature you'd like** When GIthub based authentication is enabled, it would be nice if user were able to select the email address used for creating Bookstack account. Current behaviour is that with Github driver, primary account email is selected. **Describe the benefits this feature would bring to BookStack users** Many folks have multiple email addresses on their Github profiles. Some of them being provided by the company they work for. This would allow them to specify which address is used for which instance.
OVERLORD added the 🚪 Authentication label 2026-02-05 02:17:20 +03:00
Author
Owner

@ivantomica commented on GitHub (Nov 19, 2020):

I've since learned that API call to https://api.github.com/user/emails should return all email addresses associated with user-account, their status (primary, verified). I guess selection should only be offered for verified email addresses due to security reasons (anybody can add unverified email address to their profile, and would thus get access to wiki as well).

@ivantomica commented on GitHub (Nov 19, 2020): I've since learned that API call to https://api.github.com/user/emails should return all email addresses associated with user-account, their status (primary, verified). I guess selection should only be offered for verified email addresses due to security reasons (anybody can add unverified email address to their profile, and would thus get access to wiki as well).
Author
Owner

@ssddanbrown commented on GitHub (Nov 22, 2020):

Thanks for the suggestion @ivantomica.

To be totally honest, I don't really want to go down the path of adding in edge-case functionality/interface for specific social providers.

From what I can remember, BookStack will only use the GitHub email address when registering as a new account, Any attachment between the GitHub & BookStack users are then based upon ids. You should be able to still change emails addresses in BookStack after initial registration, if wished for, or sign-up via another method then attach the GitHub account to your account afterwards.

@ssddanbrown commented on GitHub (Nov 22, 2020): Thanks for the suggestion @ivantomica. To be totally honest, I don't really want to go down the path of adding in edge-case functionality/interface for specific social providers. From what I can remember, BookStack will only use the GitHub email address when registering as a new account, Any attachment between the GitHub & BookStack users are then based upon ids. You should be able to still change emails addresses in BookStack after initial registration, if wished for, or sign-up via another method then attach the GitHub account to your account afterwards.
Author
Owner

@ivantomica commented on GitHub (Nov 22, 2020):

Agreed, we should always be reluctant when adding new "edge-case" functionality.

In this particular case though, when you give it some more thought, it isn't so wild :-)

When registering for an account, if I have domain limitation, I can't complete registration unless my primary email is in allowed domain name list. This is not so rare as many folks use their private github accounts as organization accounts as well. And as you can imagine, many folks can be in few different organizations.

My proposition was to simply allow email to be choosen during the registration, this way, you wouldn't add any security risk in the process. If only verified addresses were listed that is :-)

@ivantomica commented on GitHub (Nov 22, 2020): Agreed, we should always be reluctant when adding new "edge-case" functionality. In this particular case though, when you give it some more thought, it isn't so wild :-) When registering for an account, if I have domain limitation, I can't complete registration unless my primary email is in allowed domain name list. This is not so rare as many folks use their private github accounts as organization accounts as well. And as you can imagine, many folks can be in few different organizations. My proposition was to simply allow email to be choosen during the registration, this way, you wouldn't add any security risk in the process. If only verified addresses were listed that is :-)
Author
Owner

@ssddanbrown commented on GitHub (Nov 26, 2020):

Sure, I get the idea of it and agree that it isn't so wild, but it is still very edge-case. Including such functionality would only greatly benefit:

  • People registering on a BookStack instance where GitHub auth is available.
  • Where domain restrictions are in place.
  • Where the GitHub account has more than one email address associated and their primary email does not match the domain restriction.
  • Where the user can't use another authentication option or directly ask an admin to manually set them up an account to work around this.

It's gonna end up a fraction of a percent of use-cases.

@ssddanbrown commented on GitHub (Nov 26, 2020): Sure, I get the idea of it and agree that it isn't so wild, but it is still very edge-case. Including such functionality would only greatly benefit: - People registering on a BookStack instance where GitHub auth is available. - Where domain restrictions are in place. - Where the GitHub account has more than one email address associated and their primary email does not match the domain restriction. - Where the user can't use another authentication option or directly ask an admin to manually set them up an account to work around this. It's gonna end up a fraction of a percent of use-cases.
Author
Owner

@ssddanbrown commented on GitHub (Dec 12, 2020):

Due to the above I'm going to close this off. Thanks though for spending the time in putting forward the idea.

@ssddanbrown commented on GitHub (Dec 12, 2020): Due to the above I'm going to close this off. Thanks though for spending the time in putting forward the idea.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1949