Git command not fully support OpenID credentials #4091

New Issue

GiteaMirror · 2025-11-02T05:37:24-06:00

GiteaMirror commented

2025-11-02 05:37:24 -06:00

Originally created by @kstan79 on GitHub (Oct 10, 2019).

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

Description

I'm was authenticate user via ldap account and that work fine. Both web console and git clone/pull/push using identical user/password.

I'd setup own openid server (keycloak) and let gitea bind to it. Web console we can login through keycloak and get into gitea, but the git command it doesn't recognise same password from keycloak. I need to define another local password in order to allow commit code into repository.

I'm feel that this design is not scalable and defeat the purpose of using openid. Is it possible to have any of below solution?

git command (push/pull/clone and etc) using open id password instead of gitea local password (I think it is hard cause sometimes openid implement 2 factor authentication, that add complexity)
separate ldap and openid definition. Mean we define 'User X' login can use openid, but authentication source is ldap. The result will be web console we can login through both open id or ldap password. In 'git command' we will authenticate using ldap account password. As administrator, i can bind keycloak and git tea user into same ldap db afterwards.

Originally created by @kstan79 on GitHub (Oct 10, 2019).   - Gitea version (or commit ref): 1.9.3 - Git version: 2.7.4 - Operating system: Ubuntu Linux - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ x] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description I'm was authenticate user via ldap account and that work fine. Both web console and git clone/pull/push using identical user/password. I'd setup own openid server (keycloak) and let gitea bind to it. Web console we can login through keycloak and get into gitea, but the git command it doesn't recognise same password from keycloak. I need to define another local password in order to allow commit code into repository. I'm feel that this design is not scalable and defeat the purpose of using openid. Is it possible to have any of below solution? 1. git command (push/pull/clone and etc) using open id password instead of gitea local password (I think it is hard cause sometimes openid implement 2 factor authentication, that add complexity) 2. separate ldap and openid definition. Mean we define 'User X' login can use openid, but authentication source is ldap. The result will be web console we can login through both open id or ldap password. In 'git command' we will authenticate using ldap account password. As administrator, i can bind keycloak and git tea user into same ldap db afterwards.

GiteaMirror added the type/question label 2025-11-02 05:37:24 -06:00

GiteaMirror closed this issue

2025-11-02 05:37:25 -06:00

GiteaMirror commented

2025-11-02 05:37:27 -06:00

@zeripath commented on GitHub (Oct 10, 2019):

When passing in the password for git you can pass in either an application token, an oauth token or your password.

@zeripath commented on GitHub (Oct 10, 2019): When passing in the password for git you can pass in either an application token, an oauth token or your password.

GiteaMirror commented

2025-11-02 05:37:27 -06:00

@techknowlogick commented on GitHub (Oct 10, 2019):

Gitea doesn't have access to openID password due to it not have the password provided to it. When you enter the password for keycloak, you enter it into that system directly, and keycloak just lets us know if the authentication was successful. Whereas with ldap, Gitea itself talks to the lday server (most frequent ldap server used with Gitea is Active Directory, and also FreeIPA).

Like @zeripath has said though, there are many options you can use other than password (personally I recommend using SSH pub/priv keys for added security).

@techknowlogick commented on GitHub (Oct 10, 2019): Gitea doesn't have access to openID password due to it not have the password provided to it. When you enter the password for keycloak, you enter it into that system directly, and keycloak just lets us know if the authentication was successful. Whereas with ldap, Gitea itself talks to the lday server (most frequent ldap server used with Gitea is Active Directory, and also FreeIPA). Like @zeripath has said though, there are many options you can use other than password (personally I recommend using SSH pub/priv keys for added security).

GiteaMirror commented

2025-11-02 05:37:28 -06:00

@lunny commented on GitHub (Oct 11, 2019):

So maybe a desktop SSO support may resolve the problem. It needs git support that.

@lunny commented on GitHub (Oct 11, 2019): So maybe a desktop SSO support may resolve the problem. It needs git support that.

GiteaMirror commented

2025-11-02 05:37:28 -06:00

@guillep2k commented on GitHub (Oct 11, 2019):

@kstan79 As a git + OpenID solution is not currently possible, you may want to close this issue and open another one requesting option 2 specifically, as this issue is more or less an open question.

@guillep2k commented on GitHub (Oct 11, 2019): @kstan79 As a git + OpenID solution is not currently possible, you may want to close this issue and open another one requesting option 2 specifically, as this issue is more or less an open question.

GiteaMirror commented

2025-11-02 05:37:28 -06:00

@kstan79 commented on GitHub (Oct 11, 2019):

ok tq. i will reopen issue 2

@kstan79 commented on GitHub (Oct 11, 2019): ok tq. i will reopen issue 2

GiteaMirror referenced this issue

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

[PR #4091] [MERGED] Fix #4090 by escaping filename page/img link (without path) for short link #17237

GiteaMirror referenced this issue

2025-11-02 12:32:05 -06:00

[PR #4254] [MERGED] backport(#4091): Fix #4090 by escaping filename page/img link (without path) for short link #17302

Sign in to join this conversation.