Skip to content

Feature request: Change default authentication provider for user registration. #700

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
couling opened this issue Jan 19, 2017 · 6 comments
Closed
Labels
issue/stale type/feature Completely new functionality. Can only be merged if feature freeze is not active.

Comments

@couling
Copy link
Contributor

couling commented Jan 19, 2017

Feature request: Change default authentication provider for registration.

At the moment there are two mechanisms for creating an account:

  1. An admin creates one manually.
  2. If enabled anybody can run through the account registration procedure to create an account with LOCAL authentication.

This means that either users have to wait for a sysadmin to creat an account for them, or that sysadmins have no control over who signs up for an account. It also means that user driven registration always uses local authentication and never an alternative (eg LDAP).

It would be good if gitea could allow anyone with a valid login (eg: a valid LDAP login) to create themselves an account.


Possible further extensions to this:

  • A user attempting to log in with with a username and password which do not match a gitea user but will authorise with LDAP could be bounced to a pre-authorised account registration page ("Just add full name and email address to complete")

  • Gitea could enforce that that gitea usernames and authentication provider (LDAP) usersnames match - at least for registration.

@tboerger
Copy link
Member

There is already an open issue to provide a bootstrap config that enables ldap or other authentication sources directly from the beginning. Than nobody will be able to register on the wrong place

@couling
Copy link
Contributor Author

couling commented Jan 19, 2017

Are you referring to #209? That's quite a different issue. #209 is about automating setup from the point of view of the sysadmin during installation. This issue is about allowing users to set themselves up on an established and running instance where they already have a single-sign-on user-name and password.

@lunny lunny added this to the 1.x.x milestone Jan 20, 2017
@lunny lunny added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Jan 20, 2017
@bkcsoft
Copy link
Member

bkcsoft commented Jan 20, 2017

LDAP-authentication is already possible when the admin goes through the installation-process so I don't really see the issue here?

@strk
Copy link
Member

strk commented Jan 20, 2017 via email

@strk
Copy link
Member

strk commented Feb 23, 2017

@couling did we respond to your concern ? Can this be closed ? (spring cleanup)

@stale
Copy link

stale bot commented Feb 17, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Feb 17, 2019
@lunny lunny closed this as completed Feb 19, 2019
@lafriks lafriks removed this from the 1.x.x milestone Feb 19, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/stale type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Development

No branches or pull requests

6 participants