Default config changes

[infogulch]

I was looking through the gitea config cheat sheet and there are some changes that could be made to make it more operator friendly.

I'd like to hear your thoughts.

1. Disable registration by default

See Prevent external users from joining gitea instance.

[service]
DISABLE_REGISTRATION = True
REGISTER_MANUAL_CONFIRM = True
EMAIL_DOMAIN_ALLOWLIST = XX_your_domain_here_XX,cloudron.local
DEFAULT_USER_IS_RESTRICTED = True

I would guess that most cloudron users would want to manage gitea user accounts through cloudron instead of in the app itself. This would prevent spam and abuse of gitea instances by default. This may require some tuning, I'm not sure how carefully these configs were tested.

2. Completely disable gitea password-based signin form

I noticed gitea has these options to disable the username/password signin form entirely. This would make cloudron logins smoother because I keep forgetting and fill in my cloudron credentials to the gitea login form, which doesn't work, instead of clicking "Sign in with Cloudron".

More importantly, if this setting is changed it might eliminate the need to change and manage the admin password during first time app install, simplifying the initial setup. To ensure that users can get to the admin panel, maybe we could use the CLI to make the cloudron app owner account an administrator in start.sh.

[service]
ENABLE_PASSWORD_SIGNIN_FORM = false
ENABLE_BASIC_AUTHENTICATION = false

ENABLE_PASSWORD_SIGNIN_FORM: true: Show the password login form (for password-based login), otherwise, only show OAuth2 or passkey login methods if they are enabled. If you set it to false, maybe it also needs to set ENABLE_BASIC_AUTHENTICATION to false to completely disable password-based authentication.

[girish]

@infogulch thanks for the write up.

I have a MR going now which disables registration by default - https://git.cloudron.io/packages/gitea-app/-/merge_requests/29 . Also, adds a checklist item to disable registration in non-sso mode .

[infogulch]

Cool. What do you think about item 2?

[girish]

@infogulch I think disabling the signin form disables admin login as well. We won't put it in the package since then the first login won't work (to change admin password) . But I think it makes sense in general.

[infogulch]

Yes that's what I'm saying: I've never logged in with the root user since changing the password, I've always managed my gitea instance by giving my cloudron identity administrator privileges in the app. So maybe the admin is not even necessary. And if we just completely disable the admin login this would simplify first-time setup of the gitea app.

[girish]

Doesn't the first OIDC user need to be made an admin by logging in as admin first?

[infogulch]

What if the OIDC user can be made admin through the CLI in start.sh?

[girish]

Users are auto-created by gitea on OIDC login. So, we may not have the user object in gitea database in start.sh time.

[infogulch]

Yes I suspected that's how it would work.

What if we configure Gitea admin group claims from OIDC tokens? Can cloudron add a claim to the token when the authenticated user is an operator?

• --group-claim-name: Claim name providing group names for this source. (Optional)
• --admin-group: Group Claim value for administrator users. (Optional)

-Gitea Command Line Reference

https://github.com/search?q=repo%3Ago-gitea%2Fgitea oauth2_group_claim_name&type=code
https://github.com/search?q=repo%3Ago-gitea%2Fgitea+oauth2groupclaimname&type=code
https://github.com/search?q=repo%3Ago-gitea%2Fgitea GroupClaimName&type=code

Ok it looks like these configs are not settable by app.ini. I'll ask in the discord and post back here.

https://github.com/go-gitea/gitea/blob/b861d86f80ea7a848efb539b798bbde3c7877d02/modules/setting/oauth2.go#L63-L79

[infogulch]

Ok I found that the configuration is loaded from the login_soruce table, which has a JSON column cfg with OAuth2-specific fields. For reference it works like this:

• OAuth2 login starts in SignInOAuthCallback
  • This calls GetActiveOAuth2SourceByAuthName to get the OAuth config
  • GetActiveOAuth2SourceByAuthName loads the login configuration from the database
  • This populates a models.auth.Source struct from the login_source table
  • The Cfg field is parsed into the source-specific struct services.auth.source.oauth2.Source which contains the GroupClaimName and AdminGroup fields.
• Then SignInOAuthCallback calls function getUserAdminAndRestrictedFromGroupClaims to read these fields to get the user's admin status from the oauth claims.

I looked at my login_source table:

SELECT * FROM login_source WHERE type = 6 /*OAuth2*/ AND name = 'cloudron' AND is_active = 1;

+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+
| id | type | name     | is_sync_enabled | cfg                                                                                                                                                                                                                                                                                                                                                                                                          | created_unix | updated_unix | is_active | two_factor_policy |
+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+
|  1 |    6 | cloudron |               0 | {"Provider":"openidConnect","ClientID":"<snip>","ClientSecret":"<snip>","OpenIDConnectAutoDiscoveryURL":"https://my.<cloudron domain>/openid/.well-known/openid-configuration","CustomURLMapping":null,"IconURL":"","Scopes":["openid email profile"],"RequiredClaimName":"","RequiredClaimValue":"","GroupClaimName":"","AdminGroup":"","GroupTeamMap":"","GroupTeamMapRemoval":false,"RestrictedGroup":""} |   1752293846 |   1752293846 |         1 |                   |
+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+

Here you can see the JSON fields GroupClaimName and AdminGroup in the cfg column.

So these configuration settings can be updated today with a query like this:

UPDATE login_source
SET cfg = JSON_SET(cfg, '$.GroupClaimName', '<group claim name>', '$.AdminGroup', '<operators group name>')
WHERE type = 6 /*OAuth2*/ AND name = 'cloudron' AND is_active = 1;

Obviously it would be better if this setting was exposed in app.ini, but this is enough for testing. And we'll have a stronger case for a PR to add this if we come with a live use-case.

To me it seems like the next steps are:

1. Figure out if Cloudron even exposes the group names and the app's operators group via OAuth2 claims
2. Test to see if changing it by sql works
3. Decide if this makes sense as a default
4. Update the app to use it by default
   a. start.sh can open a subshell that tries to update these settings by direct query, checking in a loop every 5 seconds waiting for the schema to populate on first boot and for the login_source row to be created from config.
   b. Add the settings ENABLE_PASSWORD_SIGNIN_FORM = false and ENABLE_BASIC_AUTHENTICATION = false, and remove the first-time setup task to change the root password.
   c. Open an issue with Gitea to expose these settings via app.ini, remove the subshell workaround and use the exposed config options when they are available.