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

New Issue

GiteaMirror · 2025-11-02T03:15:59-06:00

GiteaMirror commented

2025-11-02 03:15:59 -06:00

Originally created by @couling on GitHub (Jan 19, 2017).

Feature request: Change default authentication provider for registration.

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

An admin creates one manually.
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.

Originally created by @couling on GitHub (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.

GiteaMirror added the type/feature issue/stale labels 2025-11-02 03:15:59 -06:00

GiteaMirror closed this issue

2025-11-02 03:15:59 -06:00

GiteaMirror commented

2025-11-02 03:16:00 -06:00

@tboerger commented on GitHub (Jan 19, 2017):

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

@tboerger commented on GitHub (Jan 19, 2017): 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

GiteaMirror commented

2025-11-02 03:16:00 -06:00

@couling commented on GitHub (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.

@couling commented on GitHub (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.

GiteaMirror commented

2025-11-02 03:16:00 -06:00

@bkcsoft commented on GitHub (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?

@bkcsoft commented on GitHub (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?

GiteaMirror commented

2025-11-02 03:16:00 -06:00

@strk commented on GitHub (Jan 20, 2017):

On Thu, Jan 19, 2017 at 10:26:12AM -0800, Philip Couling wrote:

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

This is already supported. Anyone with LDAP gets an account automatically
created upon first login. We disabled the registration and used a custom
template to provide a link to the external LDAP registration page.
Works fine.

@strk commented on GitHub (Jan 20, 2017): On Thu, Jan 19, 2017 at 10:26:12AM -0800, Philip Couling wrote: > It would be good if gitea could allow *anyone* with a valid login (eg: a valid LDAP login) to create themselves an account. This is already supported. Anyone with LDAP gets an account automatically created upon first login. We disabled the registration and used a custom template to provide a link to the external LDAP registration page. Works fine.

GiteaMirror commented

2025-11-02 03:16:00 -06:00

@strk commented on GitHub (Feb 23, 2017):

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

@strk commented on GitHub (Feb 23, 2017): @couling did we respond to your concern ? Can this be closed ? (spring cleanup)

GiteaMirror commented

2025-11-02 03:16:01 -06:00

@stale[bot] commented on GitHub (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[bot] commented on GitHub (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.

GiteaMirror referenced this issue

2025-11-02 11:42:33 -06:00

[PR #252] [MERGED] Golint fixed for modules/httplib #15260

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#252