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 filling in the GroupClaimName and AdminGroup fields in the UI works
3. Test to see if changing it by sql works
4. Decide if this makes sense as a default
5. 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.

[infogulch]

@girish So my question for you is: Does cloudron assign an oauth2 claim for groups, specifically for app operators? If not, could it?

[nebulon]

Cloudron will return the groups a user is part of. However admin or app operator are roles not groups. So an app does not know if a user is also an admin on your Cloudron or such.

Long ago we did expose this, but this usually does not map well to apps. Roles and groups often mean different things within different apps.

[infogulch]

I see. Having some impedance mismatch between cloudron roles and app groups makes sense.

What if cloudron exposed a separate "roles" claim in addition to groups? Gitea could be configured to use the cloudron role claim as Claim name providing groups for this source, then set administrator as the Group Claim value for administrator users. Or set it to operators if you want to allow every operator to act as a Gitea Site Administrator.

In this case as long as Map claimed groups to Organization teams is left blank then there's no mapping that will confuse the app.

[nebulon]

This is currently not on our list. But you should be able to use Cloudron groups for that already, just have to add the users accordingly.

[infogulch]

What I was aiming for with this was to simplify the Gitea app install process for new instances. This would:

1. Remove the step where new app owners must change the root password and save it, eliminating the initial period where new installs are vulnerable to spam and abuse, and eliminating the need for a root user at all.
2. Allow for disabling username/password entry form, streamlining cloudron logins.
3. Derive Gitea Site Administrator privileges directly from app owner/operator role, simplifying app administrator delegation.

These goals are related to the default initial configuration of the gitea app, and are thus not possible to achieve with cloudron groups.

To do this, cloudron would need to:

1. Add a role claim (maybe roles plural) to the claims returned by getClaims, corresponding to the user's role assignment for that app.
2. Accept a PR to the gitea app that configures it to use these claims to set the site administrator role, after waiting for gitea to implement the ability to configure these settings from app.ini.

I understand if you are not interested at this time.