Allow authentication to be set in app.ini / migrate all authentication to app.ini #62

@stevenroose commented on GitHub (Nov 16, 2016):

From @Unknwon on July 2, 2016 15:45

Hi... actually I'm not quite understand what you're trying to describe... but set auth info in app.ini would be acceptable, it seems a dirty workaround instead of a solution.

@stevenroose commented on GitHub (Nov 16, 2016): _From @Unknwon on July 2, 2016 15:45_ Hi... actually I'm not quite understand what you're trying to describe... but set auth info in `app.ini` would be acceptable, it seems a dirty workaround instead of a solution.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

It just seems to me that authentication settings are part of the installation configuration rather than something to do at runtime. So it should be put in app.ini instead of the database.

Many packaged versions of Gogs that are specifically made for a certain software distribution will want to automatically integrate Gogs with the authentication scheme they use during the installation period. That is currently impossible because the authentication section from Gogs can only be accessed while it is running through the web interface or through the underlying SQL DB.

So what I propose is a new app.ini section f.e. [authentication] or [ldap] where the required LDAP parameters can be provided.

Examples of apps using config files for auth (I think the ones that don't are actually very rare) are: Owncloud, Seafile, Roundcube, Ampache, Baikal and actually all of the ones that I came across when packaging apps for YunoHost.

@stevenroose commented on GitHub (Nov 16, 2016): It just seems to me that authentication settings are part of the installation configuration rather than something to do at runtime. So it should be put in `app.ini` instead of the database. Many packaged versions of Gogs that are specifically made for a certain software distribution will want to automatically integrate Gogs with the authentication scheme they use during the installation period. That is currently impossible because the authentication section from Gogs can only be accessed while it is running through the web interface or through the underlying SQL DB. So what I propose is a new `app.ini` section f.e. `[authentication]` or `[ldap]` where the required LDAP parameters can be provided. Examples of apps using config files for auth (I think the ones that don't are actually very rare) are: [Owncloud](https://github.com/YunoHost-Apps/owncloud_ynh/blob/master/conf/config.json#L13), [Seafile](https://github.com/YunoHost-Apps/seafile_ynh/blob/4e82eba40931cd168dd66a9c3e0f3b3611e46cb0/scripts/install#L100), [Roundcube](https://github.com/YunoHost-Apps/roundcube_ynh/blob/master/conf/config.inc.php#L103), [Ampache](https://github.com/YunoHost-Apps/ampache_ynh/blob/master/conf/ampache.cfg.php#L609), [Baikal](https://github.com/YunoHost-Apps/baikal_ynh/blob/master/conf/config.php#L43) and actually all of the ones that I came across when packaging apps for YunoHost.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

From @Unknwon on July 7, 2016 23:53

Gogs supports theoretically unlimited authentication sources, that's why config in file is not possible.

@stevenroose commented on GitHub (Nov 16, 2016): _From @Unknwon on July 7, 2016 23:53_ Gogs supports theoretically unlimited authentication sources, that's why config in file is not possible.

GiteaMirror commented

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

@stevenroose commented on GitHub (Nov 16, 2016):

From @jerrykan on July 8, 2016 12:48

Having to configure the authentication sources in the DB is an impediment to being able to deploy gogs using configuration management tools. I imagine it would be possible to implement any number of authentication sources using the following sort of scheme in the app.ini

[auth]
backend = ldap_ad, ldap_openldap, pam

[auth_ldap_ad]
type = ldap
... (other ldap specific settings) ..

[auth_ldap_ad]
type = ldap
... (ldap specific settings) ..

[auth_pam]
type = pam
... (pam specific settings) ..

the backend value in the [auth] section defines the priority of the authentication sources that are enabled and are references to the [auth_*] sections which contain the configuration for each authentication source.

It may require a little more processing of the app.ini file to load the configuration settings, but it should be possible.

@stevenroose commented on GitHub (Nov 16, 2016): _From @jerrykan on July 8, 2016 12:48_ Having to configure the authentication sources in the DB is an impediment to being able to deploy gogs using configuration management tools. I imagine it would be possible to implement any number of authentication sources using the following sort of scheme in the `app.ini` ``` [auth] backend = ldap_ad, ldap_openldap, pam [auth_ldap_ad] type = ldap ... (other ldap specific settings) .. [auth_ldap_ad] type = ldap ... (ldap specific settings) .. [auth_pam] type = pam ... (pam specific settings) .. ``` the `backend` value in the `[auth]` section defines the priority of the authentication sources that are enabled and are references to the `[auth_*]` sections which contain the configuration for each authentication source. It may require a little more processing of the `app.ini` file to load the configuration settings, but it should be possible.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

From @Unknwon on July 8, 2016 13:6

@jerrykan good point, but I think we probably should just make a new file named auth_sources.ini or auth_sources.conf?

@stevenroose commented on GitHub (Nov 16, 2016): _From @Unknwon on July 8, 2016 13:6_ @jerrykan good point, but I think we probably should just make a new file named `auth_sources.ini` or `auth_sources.conf`?

GiteaMirror commented

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

@stevenroose commented on GitHub (Nov 16, 2016):

From @jerrykan on July 9, 2016 14:2

@Unknwon my personal preference would be to keep everything in app.ini so there is only one file to configure/manage, but I don't see any major issues if it were to be implemented in another config file.

@stevenroose commented on GitHub (Nov 16, 2016): _From @jerrykan on July 9, 2016 14:2_ @Unknwon my personal preference would be to keep everything in `app.ini` so there is only one file to configure/manage, but I don't see any major issues if it were to be implemented in another config file.

GiteaMirror commented

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

@stevenroose commented on GitHub (Nov 16, 2016):

From @Unknwon on July 9, 2016 14:15

app.ini is more about site configuration, but authentication sources are site data in my opinion.

@stevenroose commented on GitHub (Nov 16, 2016): _From @Unknwon on July 9, 2016 14:15_ `app.ini` is more about site configuration, but authentication sources are site data in my opinion.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

From @jerrykan on July 10, 2016 13:19

I don't see configuring authentication backends as being any different to configuring the database or mail servers. It is site specific, generally configured during initial setup, and rarely changes. So I wouldn't really consider the it data.

@stevenroose commented on GitHub (Nov 16, 2016): _From @jerrykan on July 10, 2016 13:19_ I don't see configuring authentication backends as being any different to configuring the database or mail servers. It is site specific, generally configured during initial setup, and rarely changes. So I wouldn't really consider the it data.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

@Unknwon Can you point me to where auth configuration is located? Perhaps I can try and implement the migration myself.

@stevenroose commented on GitHub (Nov 16, 2016): @Unknwon Can you point me to where auth configuration is located? Perhaps I can try and implement the migration myself.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 16, 2016):

From @Unknwon on August 3, 2016 4:23

@stevenroose login_source table.

@stevenroose commented on GitHub (Nov 16, 2016): _From @Unknwon on August 3, 2016 4:23_ @stevenroose `login_source` table.

GiteaMirror commented

@lunny commented on GitHub (Nov 17, 2016):

I don't think that storeing LDAP configuration on app.ini is a better idea. But I think It could be done via Gitea APIs. We can provide LDAP configuration API so that you can add it just call the APIs.

@lunny commented on GitHub (Nov 17, 2016): I don't think that storeing LDAP configuration on `app.ini` is a better idea. But I think It could be done via Gitea APIs. We can provide LDAP configuration API so that you can add it just call the APIs.

GiteaMirror commented

@strk commented on GitHub (Nov 17, 2016):

It does make sense to me for site configuration to be in a configuration file rather than in the database, I've actually found myself in the troubling situation of having to migrate a database table to fully replicate a configuration (rather than just copying the custom/ directory over)

@strk commented on GitHub (Nov 17, 2016): It does make sense to me for site configuration to be in a configuration file rather than in the database, I've actually found myself in the troubling situation of having to migrate a database table to fully replicate a configuration (rather than just copying the custom/ directory over)

GiteaMirror commented

@lunny commented on GitHub (Nov 21, 2016):

Of course, we could add some subcommand to gitea admin command to finish the work.

@lunny commented on GitHub (Nov 21, 2016): Of course, we could add some subcommand to `gitea admin` command to finish the work.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 21, 2016):

Setting up authentication is part of the installation. Right now if you
only want LDAP users, there's a catch-22 because you need to login to
add an authentication method but you cannot login because LDAP is not
configured yet. The same holds with any other type except the default one.

I've setup quite a number of self-hosted web services and all of them
store auth config statically.

On 21-11-16 02:54, Lunny Xiao wrote:

Of course, we could add some subcommand to |gitea admin| command to
finish the work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/go-gitea/gitea/issues/183#issuecomment-261824704,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0F3M7NQbhDhPbr4wdjhF_XrYBvYx1Dks5rAPnGgaJpZM4KzyA0.

@stevenroose commented on GitHub (Nov 21, 2016): Setting up authentication is part of the installation. Right now if you only want LDAP users, there's a catch-22 because you need to login to add an authentication method but you cannot login because LDAP is not configured yet. The same holds with any other type except the default one. I've setup quite a number of self-hosted web services and all of them store auth config statically. On 21-11-16 02:54, Lunny Xiao wrote: > Of course, we could add some subcommand to |gitea admin| command to > finish the work. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > https://github.com/go-gitea/gitea/issues/183#issuecomment-261824704, > or mute the thread > https://github.com/notifications/unsubscribe-auth/AA0F3M7NQbhDhPbr4wdjhF_XrYBvYx1Dks5rAPnGgaJpZM4KzyA0.

GiteaMirror commented

@strk commented on GitHub (Nov 21, 2016):

I also think the authentication mechanism should be refactored to be explicit about which auth method is in use from the web UI. It should also help adding more complex auth methods (like OAuth/OpenID)

@strk commented on GitHub (Nov 21, 2016): I also think the authentication mechanism should be refactored to be explicit about which auth method is in use from the web UI. It should also help adding more complex auth methods (like OAuth/OpenID)

GiteaMirror commented

@lunny commented on GitHub (Nov 22, 2016):

Or we can add LDAP or SMTP config on installation page? And this is not very difficult, since we have already authentication page on admin panel.

@lunny commented on GitHub (Nov 22, 2016): Or we can add LDAP or SMTP config on installation page? And this is not very difficult, since we have already authentication page on admin panel.

GiteaMirror commented

@jerrykan commented on GitHub (Nov 22, 2016):

For most of the systems we manage that have to use an "install page" to install/configure a system is a real pain. Every configuration management tool available makes it easy to mange plain text configuration files, hence why it is so desirable for configuration to be done in config files instead of in the DB. Even for advanced users who don't use config management tools being able to edit a file and restart the service is much easier than running some SQL on a DB or make and API request to make configuration changes. With configuration files you also don't end up in a situation where authentication breaks and you can't log into the system to make the necessary configuration changes to fix things.

Having "install pages" are useful to help new users get something up and going, but forcing advanced users to use them is an anti-feature, when all they want to do is copy a pre-made configuration file into place and be done with the configuration side of things.

@jerrykan commented on GitHub (Nov 22, 2016): For most of the systems we manage that have to use an "install page" to install/configure a system is a real pain. Every configuration management tool available makes it easy to mange plain text configuration files, hence why it is so desirable for configuration to be done in config files instead of in the DB. Even for advanced users who don't use config management tools being able to edit a file and restart the service is much easier than running some SQL on a DB or make and API request to make configuration changes. With configuration files you also don't end up in a situation where authentication breaks and you can't log into the system to make the necessary configuration changes to fix things. Having "install pages" are useful to help new users get something up and going, but forcing advanced users to use them is an anti-feature, when all they want to do is copy a pre-made configuration file into place and be done with the configuration side of things.

GiteaMirror commented

@lunny commented on GitHub (Nov 22, 2016):

So that, I think maybe https://github.com/go-gitea/gitea/issues/209 will resolve this.

@lunny commented on GitHub (Nov 22, 2016): So that, I think maybe https://github.com/go-gitea/gitea/issues/209 will resolve this.

GiteaMirror commented

@stevenroose commented on GitHub (Nov 22, 2016):

@jerrykan I totally agree. Install pages are a pain in the ass for platforms like YunoHost that want to ship a preconfigured version.

@strk About explicitly mentioning the auth method, I'm not sure. It makes sense for OpenID, but not for the different username/password types. Username/password methods with different DB types (because LDAP is just another DB to store user information) should all use the regular username/password fields. While I agree for the more exotic methods, an explicit button/whatever is good.

@stevenroose commented on GitHub (Nov 22, 2016): @jerrykan I totally agree. Install pages are a pain in the ass for platforms like YunoHost that want to ship a preconfigured version. @strk About explicitly mentioning the auth method, I'm not sure. It makes sense for OpenID, but not for the different username/password types. Username/password methods with different DB types (because LDAP is just another DB to store user information) should all use the regular username/password fields. While I agree for the more exotic methods, an explicit button/whatever is good.

GiteaMirror commented

@ptman commented on GitHub (Mar 13, 2017):

I agree that all (non-per-user) configuration should be possible to make via a config file.

@stevenroose but for a quick work-around, how tied is gitea/xorm to the schema version (apparently stored in the version table)? Can you just create an SQL script that would setup the bare minimum schema and values for configuring LDAP and then let the first run upgrade the schema to whatever is the current version?

@ptman commented on GitHub (Mar 13, 2017): I agree that all (non-per-user) configuration should be possible to make via a config file. @stevenroose but for a quick work-around, how tied is gitea/xorm to the schema version (apparently stored in the version table)? Can you just create an SQL script that would setup the bare minimum schema and values for configuring LDAP and then let the first run upgrade the schema to whatever is the current version?

GiteaMirror commented

@phtan commented on GitHub (Apr 15, 2018):

For what it's worth, [at]Unknwon claims he has implemented something in Gogs, on 12th of April 2018 (GMT +8). Here's the link: https://github.com/gogits/gogs/issues/3142#issuecomment-380815756

@phtan commented on GitHub (Apr 15, 2018): For what it's worth, [at]Unknwon claims he has implemented something in Gogs, on 12th of April 2018 (GMT +8). Here's the link: [https://github.com/gogits/gogs/issues/3142#issuecomment-380815756](https://github.com/gogits/gogs/issues/3142#issuecomment-380815756)

GiteaMirror commented

@khaledkbadr commented on GitHub (Jun 26, 2018):

So is this feature frozen, declined or will be implemented in the future?

@khaledkbadr commented on GitHub (Jun 26, 2018): So is this feature frozen, declined or will be implemented in the future?

GiteaMirror commented

@strk commented on GitHub (Jun 27, 2018):

I think it's waiting for someone (you?) to implement it

@strk commented on GitHub (Jun 27, 2018): I think it's waiting for someone (you?) to implement it

GiteaMirror commented

@stevenroose commented on GitHub (Jul 30, 2018):

@strk, did you have the chance to take a look at unknwon's supposed implementation?

@stevenroose commented on GitHub (Jul 30, 2018): @strk, did you have the chance to take a look at unknwon's supposed implementation?

GiteaMirror commented

@yobert commented on GitHub (Sep 5, 2018):

I worked around this with a post-configure script that I run after the app starts up:
post-configure.txt

@yobert commented on GitHub (Sep 5, 2018): I worked around this with a post-configure script that I run after the app starts up: [post-configure.txt](https://github.com/go-gitea/gitea/files/2353547/post-configure.txt)

GiteaMirror commented

@yobert commented on GitHub (Sep 5, 2018):

^ That example is for adding PAM authentication

@yobert commented on GitHub (Sep 5, 2018): ^ That example is for adding PAM authentication

GiteaMirror commented

@strk commented on GitHub (Mar 29, 2019):

@stevenroose I didn't have a chance to look at Googs implementation but that comment is really interesting.

@strk commented on GitHub (Mar 29, 2019): @stevenroose I didn't have a chance to look at Googs implementation but [that comment](https://github.com/gogs/gogs/issues/3142#issuecomment-380815756) is really interesting.

GiteaMirror commented

@lunny commented on GitHub (Mar 29, 2019):

Since gitea admin auth command line could manage auth source, I think this issue maybe not necessary.

@lunny commented on GitHub (Mar 29, 2019): Since `gitea admin auth` command line could manage auth source, I think this issue maybe not necessary.

GiteaMirror commented

@DblK commented on GitHub (May 28, 2019):

According to the docs (https://docs.gitea.io/en-us/command-line/) there is only a command for oauth.
Is there any for ldap (or other sources)?

Is there anybody who are being able to fully automate install of gitea without any login first?

@DblK commented on GitHub (May 28, 2019): According to the docs (https://docs.gitea.io/en-us/command-line/) there is only a command for oauth. Is there any for ldap (or other sources)? Is there anybody who are being able to fully automate install of gitea without any login first?

GiteaMirror commented

@zeripath commented on GitHub (May 28, 2019):

There's a PR to add ldap configuration but it's sort of languishing because no-one has had a chance to look at it. (#6681)

@zeripath commented on GitHub (May 28, 2019): There's a PR to add ldap configuration but it's sort of languishing because no-one has had a chance to look at it. (#6681)

GiteaMirror commented

@6543 commented on GitHub (Sep 7, 2020):

./gitea admin auth --help
NAME:
   Gitea admin auth - Modify external auth providers

USAGE:
   Gitea admin auth command [command options] [arguments...]

COMMANDS:
     add-oauth           Add new Oauth authentication source
     update-oauth        Update existing Oauth authentication source
     add-ldap            Add new LDAP (via Bind DN) authentication source
     update-ldap         Update existing LDAP (via Bind DN) authentication source
     add-ldap-simple     Add new LDAP (simple auth) authentication source
     update-ldap-simple  Update existing LDAP (simple auth) authentication source
     list                List auth sources
     delete              Delete specific auth source

I think this issue can be closed now ...

@6543 commented on GitHub (Sep 7, 2020): ```sh ./gitea admin auth --help NAME: Gitea admin auth - Modify external auth providers USAGE: Gitea admin auth command [command options] [arguments...] COMMANDS: add-oauth Add new Oauth authentication source update-oauth Update existing Oauth authentication source add-ldap Add new LDAP (via Bind DN) authentication source update-ldap Update existing LDAP (via Bind DN) authentication source add-ldap-simple Add new LDAP (simple auth) authentication source update-ldap-simple Update existing LDAP (simple auth) authentication source list List auth sources delete Delete specific auth source ``` I think this issue can be closed now ...

GiteaMirror commented