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

[stevenroose]

From @stevenroose on May 28, 2016 0:38

We are trying to package Gogs to work with YunoHost, but this issue affects anyone packaging Gogs automatic installation.

We want to enable LDAP authentication during installation, but when automating the installation, it is hard to inject the authentication config into the SQL table because the table is only initialized on the first run.
Since the app.ini is the place we can manipulate Gogs configuration for automated installation, ideally authentication configuration should be here too.

Since I have no idea of how authentication is implemented in general, I don't know if there are arguments why authentication should be in SQL at all. If there are no fundamental arguments, I would be willing to try and migrate authentication config to app.ini, making sure compatibility is maintained for upgrading users.

Copied from original issue: gogs/gogs#3142

[stevenroose]

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]

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]

From @unknwon on July 7, 2016 23:53

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

[stevenroose]

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]

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]

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]

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]

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]

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

[stevenroose]

From @unknwon on August 3, 2016 4:23

@stevenroose login_source table.

[lunny]

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.

[strk]

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)

[lunny]

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

[stevenroose]

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
#183 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0F3M7NQbhDhPbr4wdjhF_XrYBvYx1Dks5rAPnGgaJpZM4KzyA0.

[strk]

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)

[lunny]

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.

[jerrykan]

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.

[lunny]

So that, I think maybe #209 will resolve this.

[stevenroose]

@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.

[ptman]

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?

[phtan]

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: gogs/gogs#3142 (comment)

[khaledkbadr]

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

[strk]

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

[stevenroose]

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

[yobert]

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

[yobert]

^ That example is for adding PAM authentication

[strk]

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

[lunny]

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

[DblK]

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?

[zeripath]

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)

[6543]

./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 ...

[jerrykan]

@6543 Does the git admin auth command store the configuration in the app.ini file or in the database? if it is just updating the configuration in the database then it isn't solving the use-case outlined in this issue.

[6543]

no auth is stored in db

[techknowlogick]

closing as via CLI is how we've chosen to go, and this method works for many different packagings of Gitea, even our Helm-chart uses the CLI and I've seen customized docker images use entrypoints with the CLI.