-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Allow authentication to be set in app.ini / migrate all authentication to app.ini #183
Comments
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 |
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 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 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. |
From @unknwon on July 7, 2016 23:53 Gogs supports theoretically unlimited authentication sources, that's why config in file is not possible. |
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
the It may require a little more processing of the |
From @unknwon on July 9, 2016 14:15
|
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. |
@unknwon Can you point me to where auth configuration is located? Perhaps I can try and implement the migration myself. |
From @unknwon on August 3, 2016 4:23 @stevenroose |
I don't think that storeing LDAP configuration on |
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) |
Of course, we could add some subcommand to |
Setting up authentication is part of the installation. Right now if you I've setup quite a number of self-hosted web services and all of them On 21-11-16 02:54, Lunny Xiao wrote:
|
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) |
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. |
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. |
So that, I think maybe #209 will resolve this. |
@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. |
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? |
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) |
So is this feature frozen, declined or will be implemented in the future? |
I think it's waiting for someone (you?) to implement it
|
@strk, did you have the chance to take a look at unknwon's supposed implementation? |
I worked around this with a post-configure script that I run after the app starts up: |
^ That example is for adding PAM authentication |
@stevenroose I didn't have a chance to look at Googs implementation but that comment is really interesting. |
Since |
According to the docs (https://docs.gitea.io/en-us/command-line/) there is only a command for oauth. Is there anybody who are being able to fully automate install of gitea without any login first? |
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) |
./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 Does the |
no auth is stored in db |
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. |
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
The text was updated successfully, but these errors were encountered: