feat: manage bot accounts from the admin UI, API and CLI#38181
Conversation
GiteaBot
added
the
lgtm/need 2
github-actions
Bot
added
the
type/feature
…dlers Extract the duplicated "scope-*" form parsing into auth.AccessTokenScopeFromForm and use it from both the user-facing ApplicationsPost and the new admin bot-token handler.
|
Maybe it should have a complete design document before going deeper in this field: what a bot user can do, what they can't. |
That's another design problem. For a large instance, org admins also need "bot" users (IIRC some issues also mentioned the cases), then the site admin shouldn't be the only people who can manage "bot" users if the requirement is real. So, if it would become a widely-useful design for production, I think a complete design is needed. update: I didn't mean "org admin manages bot users" is a must, such feature can also be rejected. I just meant it needs a document to clarify the whole design. |
There are something like "reverse proxy auth", will the user with the same name as a bot be able to sign-in via reverse proxy auth? |
|
Would it be possible to convert regular user to bot? |
|
Bot accounts are meant for token-based automation only, but the reverse-proxy and external-source (LDAP/SMTP/PAM) auth paths resolved users by name/email without checking the user type. A bot whose name or email matched a proxy header or external identity could obtain an interactive session. Guard reverse-proxy auth and the UserSignIn external-source fallback so only individual users may sign in interactively, matching the existing local-password and OAuth2 behavior. Add regression tests covering both. Assisted-by: Claude:claude-opus-4-8
Allow a site admin to convert an existing account between the individual
and bot types. Only individual <-> bot is permitted; organizations and
reserved types are rejected.
When converting to a bot the account becomes a local, token-only account:
password, auth source and persisted sessions are cleared, OAuth2
applications/grants and external login links are removed, while access
tokens and owned content (repositories, org membership, ...) are kept.
Exposed through the admin Edit User page (User Type dropdown), the API
(POST /admin/users/{username}/convert-type) and the CLI
(gitea admin user change-type), all backed by user_service.ConvertUserType.
The CLI user-type parsing is shared with "user create".
Assisted-by: Claude:claude-opus-4-8
Document the bot account model: definition, the no-interactive-sign-in guarantee across all auth paths, the capability matrix, and the individual <-> bot conversion rules with every side effect spelled out. Assisted-by: Claude:claude-opus-4-8
|
addressed and added a design doc in fab3275 |
bircni
changed the title
- reject and clear passwords when creating a bot via the admin UI, so bots stay passwordless like the CLI and edit-user paths already enforce - wrap the individual->bot credential teardown in a transaction so a mid-sequence failure cannot leave a half-converted account - guard DeleteBotToken so the admin bot-token route only acts on bots Assisted-by: Claude Code:claude-opus-4-8
|
Would probably be better as separate dangerous button "Convert to bot user" (similar how repos have converting mirror to regular repo) |
@lafriks adjusted |
|
When switching a bot user to an individual user, the email might need to be filled? For a bot user, email might not be a required field? |
No, email won't be missing. Bot users are required to have an email at creation in both paths (web form It'd only become an issue if you later make email optional for bots but idk why because you need to have an email if the bot commits... |
lafriks
left a comment
lafriks
left a comment
There was a problem hiding this comment.
Also when converting std user to bot does it clear notifications etc or does bot users receive them. Currently it's one of pain points for users that are used as a bot users that they receive a lot of notifications and unnecessary bloat notification db table
GiteaBot
added
lgtm/need 1
|
1 bot user have 3 levels. Global bot user, user's bot user and org's bot user. |
|
At this point shouldn't it be a new table? Users have no concept of ownership between each other and bot should have no more access than it's owner. |
|
The relationship could be another new table. |
lunny
added
the
docs-update-needed
|
@lunny @TheFox0x7 isn't this completely out of scope here? |
|
It very much is. I really don't get how bots ended up mixed with users... but that's a topic for later resolution. |
|
It's better to have a filter in admin user list for different user type
Related but out of the scope of this PR. |
6 participants
Bot accounts: admin UI, token management, type conversion, and auth hardening
Builds first-class bot account (
UserTypeBot) support, addressing the designquestions raised.
Create & manage (admin UI)
auth-source, login-name, password and "must change password" fields are hidden.
since bots can't sign in to manage their own tokens.
Convert existing accounts (new)
A site admin can convert an account between individual and bot via:
POST /admin/users/{username}/convert-type,gitea admin user change-type --username <name> --user-type bot|individual.Only individual ↔ bot is allowed (organizations/reserved types are rejected —
fixing the "why can an org become an individual?" problem from #33758). Every side
effect is explicit:
Bot → Individual just flips the type; the admin then sets a password to enable login.
Auth hardening (security)
Bots are non-interactive, but the reverse-proxy and external-source (LDAP/SMTP/PAM)
auth paths resolved users by name/email without a type check — a bot matching a proxy
header or external identity could get an interactive session. Both paths now require
an individual user, matching local-password and OAuth2. Regression tests included.
Screenshots