Over-zealous username validation in UI #1875

New Issue

GiteaMirror · 2025-11-02T04:16:10-06:00

GiteaMirror commented

2025-11-02 04:16:10 -06:00

Originally created by @mrichar1 on GitHub (Jun 6, 2018).

Gitea version (or commit ref): 1.4.1
Git version: 1.8.3.1
Operating system: Redhat EL7.4
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

We use kerberos via apache to authenticate hosts to gitea. Hosts have kerberos principals of the form git/host.example.com@EXAMPLE.COM which get translated to the username git/host.example.com

When we set ENABLE_REVERSE_PROXY_AUTO_REGISTRATION to true then these accounts are correctly created in gitea when the host runs git commands against our server. However since the account is 'new' it is not in the appropriate teams, so the first run fails, and we then have to set up team membership etc and re-run the processes.

To fix this I'm trying to pre-create these accounts using the UI - however when I try to create a new user with name git/host.example.com I receive the error Username must be valid alphanumeric, dash(-_) or dot characters.

Since auto-generated usernames with these characters seem to work fine, would it be possible to alter this validation to allow a broader range of usernames, filtering only those which would make gitea actually fail?

Originally created by @mrichar1 on GitHub (Jun 6, 2018). - Gitea version (or commit ref): 1.4.1 - Git version: 1.8.3.1 - Operating system: Redhat EL7.4 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description We use kerberos via apache to authenticate hosts to gitea. Hosts have kerberos principals of the form `git/host.example.com@EXAMPLE.COM` which get translated to the username `git/host.example.com` When we set `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION` to `true` then these accounts are correctly created in gitea when the host runs git commands against our server. However since the account is 'new' it is not in the appropriate teams, so the first run fails, and we then have to set up team membership etc and re-run the processes. To fix this I'm trying to pre-create these accounts using the UI - however when I try to create a new user with name `git/host.example.com` I receive the error `Username must be valid alphanumeric, dash(-_) or dot characters.` Since auto-generated usernames with these characters seem to work fine, would it be possible to alter this validation to allow a broader range of usernames, filtering only those which would make gitea actually fail?

GiteaMirror added the type/proposal topic/authentication labels 2025-11-02 04:16:10 -06:00

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@lafriks commented on GitHub (Jun 6, 2018):

/ can not be allowed as that could break functionality and even rise security issues

@lafriks commented on GitHub (Jun 6, 2018): `/` can not be allowed as that could break functionality and even rise security issues

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@mrichar1 commented on GitHub (Jun 6, 2018):

gitea currently allows / in usernames through auto-creation of accounts, and I have several accounts which seem to function correctly with such names. I guess this means that the auto-creation code doesn't follow the same codepath as the UI/API use?

I'm interested to know what security issues might arise from the username containing unexpected characters... I'd hope that all such fields were only ever used with appropriate escaping, with parameterized queries etc to avoid sql injection and similar issues.

I'd obviously be keen to keep / in usernames, since this is useful functionality to us - and I'd argue that it would be better to relax the validation and instead test what actually happens with extra characters.
That way the code can be improved to handle these cases, instead of arbitrarily limiting them because of the unknown effects they might have (especially since, as we can see here, there are unexpected routes to them existing!)

@mrichar1 commented on GitHub (Jun 6, 2018): gitea currently allows `/` in usernames through auto-creation of accounts, and I have several accounts which seem to function correctly with such names. I guess this means that the auto-creation code doesn't follow the same codepath as the UI/API use? I'm interested to know what security issues might arise from the username containing unexpected characters... I'd hope that all such fields were only ever used with appropriate escaping, with parameterized queries etc to avoid sql injection and similar issues. I'd obviously be keen to keep `/` in usernames, since this is useful functionality to us - and I'd argue that it would be better to relax the validation and instead test what actually happens with extra characters. That way the code can be improved to handle these cases, instead of arbitrarily limiting them because of the unknown effects they might have (especially since, as we can see here, there are unexpected routes to them existing!)

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@gszy commented on GitHub (Jul 29, 2018):

What’s your opinion on allowing @ in usernames?

@gszy commented on GitHub (Jul 29, 2018): What’s your opinion on allowing `@` in usernames?

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@lafriks commented on GitHub (Jul 29, 2018):

Also quite risky to break something. Would all git clients support such urls?

@lafriks commented on GitHub (Jul 29, 2018): Also quite risky to break something. Would all git clients support such urls?

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@gszy commented on GitHub (Jul 29, 2018):

TL; DR: don’t know…

git check-ref-format --branch 'a@a' returns 0, but man git-push doesn’t explain what characters are allowed in path/to/repo (in ssh://[user@]host.xz[:port]/path/to/repo.git/ example). Neither GitHub nor GitLab allow @ in usernames or project names.

@ is commonly used to mention a user or to refer to specific commit. Unless username’s first character is @ or it looks like me@something‑that‑looks‑like‑commit‑SHA, that shouldn’t be a very big problem, though it would be if we could refer to branches, like me@master (could be solved with a config option).

@gszy commented on GitHub (Jul 29, 2018): TL; DR: don’t know… `git check-ref-format --branch 'a@a'` returns 0, but `man git-push` doesn’t explain what characters are allowed in `path/to/repo` (in `ssh://[user@]host.xz[:port]/path/to/repo.git/` example). Neither GitHub nor GitLab allow `@` in usernames or project names. `@` is commonly used to mention a user or to refer to specific commit. Unless username’s first character is `@` or it looks like `me@something‑that‑looks‑like‑commit‑SHA`, that shouldn’t be a very big problem, though it would be if we could refer to branches, like `me@master` (could be solved with a config option).

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@lafriks commented on GitHub (Jul 29, 2018):

I do think that we should stick to current behaviour to not break things and keep compatibility with future changes (especially if we implement projects/groups under organizations).

@lafriks commented on GitHub (Jul 29, 2018): I do think that we should stick to current behaviour to not break things and keep compatibility with future changes (especially if we implement projects/groups under organizations).

GiteaMirror commented

2025-11-02 04:16:11 -06:00

@cwchristerw commented on GitHub (Aug 16, 2020):

I need "-" to work in org name when transferring repo between orgs. When trying to transfer repository from "cwinfo-private" to "warengroup-private". UI will show error "The new owner name is not valid."

@cwchristerw commented on GitHub (Aug 16, 2020): I need "-" to work in org name when transferring repo between orgs. When trying to transfer repository from "cwinfo-private" to "warengroup-private". UI will show error "The new owner name is not valid."

GiteaMirror commented

2025-11-02 04:16:12 -06:00

@silverwind commented on GitHub (May 31, 2024):

I think we should align our validation for org and repo name to a common denominator among forges like GitHub/GitLab. GitHub for example allow - as repo name, but not as a org name.

The most accurate description of what is allowed in repos is this:

it looks like github allows [A-Za-z0-9_.-], and transforms all other characters to "-".

For orgs:

The name may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

@silverwind commented on GitHub (May 31, 2024): I think we should align our validation for org and repo name to a common denominator among forges like GitHub/GitLab. GitHub for example allow `-` as repo name, but not as a org name. The most accurate description of what is allowed in repos is [this](https://stackoverflow.com/a/59082561/808699): > it looks like github allows [A-Za-z0-9_.-], and transforms all other characters to "-". For orgs: > The name may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

GiteaMirror commented

2025-11-02 04:16:12 -06:00

@silverwind commented on GitHub (May 31, 2024):

So maybe these, and they could be made configurable I suppose.

^[A-Za-z0-9_.-]+$ for repos
^(?![-])[A-Za-z0-9]+(?:[-][A-Za-z0-9]+)*?(?<!-)$ for orgs

@silverwind commented on GitHub (May 31, 2024): So maybe these, and they could be made configurable I suppose. - `^[A-Za-z0-9_.-]+$` for repos - `^(?![-])[A-Za-z0-9]+(?:[-][A-Za-z0-9]+)*?(?<!-)$` for orgs

GiteaMirror commented

2025-11-02 04:16:12 -06:00

@silverwind commented on GitHub (Sep 5, 2025):

As per https://github.com/go-gitea/gitea/issues/35408, org names, contrary to user names can at least end in a - and also --, so likely "cannot begin or end with a hyphen" does not apply to org names, only to user names.

@silverwind commented on GitHub (Sep 5, 2025): As per https://github.com/go-gitea/gitea/issues/35408, org names, contrary to user names can at least end in a `-` and also `--`, so likely "cannot begin or end with a hyphen" does not apply to org names, only to user names.

GiteaMirror referenced this issue

2025-11-02 12:02:18 -06:00

[PR #1875] [MERGED] Run unused test #16100

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1875