First authorization via OAUTH fails #13195

@yp05327 commented on GitHub (Jun 27, 2024):

It seems that this issue is similar to #30991?

Maybe OAUTH_USER comes from here:
e124b8bb8f/src/shared/Core/GenericOAuthConfig.cs (L143)

@yp05327 commented on GitHub (Jun 27, 2024): It seems that this issue is similar to #30991? Maybe `OAUTH_USER` comes from here: https://github.com/git-ecosystem/git-credential-manager/blob/e124b8bb8f4a53301e0d9d947c075519f75ff222/src/shared/Core/GenericOAuthConfig.cs#L143

GiteaMirror commented

@yp05327 commented on GitHub (Jun 27, 2024):

I found a related issue ( maybe ) in GCM:
https://github.com/git-ecosystem/git-credential-manager/issues/1408

Maybe this is a problem from upstream (not directly related) ?

@yp05327 commented on GitHub (Jun 27, 2024): I found a related issue ( maybe ) in GCM: https://github.com/git-ecosystem/git-credential-manager/issues/1408 Maybe this is a problem from upstream (not directly related) ?

GiteaMirror commented

See https://gist.github.com/Remmert-PBE/1ccecd8d82c4b19d700835bff1b3567b

@Remmert-PBE commented on GitHub (Jun 27, 2024):

@yp05327 Good find, thats exactly what happens on my system. I ran a GCM_TRACE a few days back and it is similar to the one in the gcm issue. In my log the first push ends with the command erase and only on the 2nd push a new token is saved.

Now the question is, which tool is at fault?

@Remmert-PBE commented on GitHub (Jun 27, 2024): @yp05327 Good find, thats exactly what happens on my system. I ran a GCM_TRACE a few days back and it is similar to the one in the [gcm issue](https://github.com/git-ecosystem/git-credential-manager/issues/1408). In my log the first push ends with the command erase and only on the 2nd push a new token is saved. See https://gist.github.com/Remmert-PBE/1ccecd8d82c4b19d700835bff1b3567b Now the question is, which tool is at fault?

GiteaMirror commented

@meruiden commented on GitHub (Jul 13, 2024):

I have the same, after a little while, when I push again, the first time always fails, second time succeeds. im also logged in via the vscode -> oauth in browser

@meruiden commented on GitHub (Jul 13, 2024): I have the same, after a little while, when I push again, the first time always fails, second time succeeds. im also logged in via the vscode -> oauth in browser

GiteaMirror commented

@uujwnqjgim commented on GitHub (Aug 9, 2024):

First push fails with:

remote: Verify
fatal: Authentication failed for ...

second git push is ok

@uujwnqjgim commented on GitHub (Aug 9, 2024): First push fails with: remote: Verify fatal: Authentication failed for ... second git push is ok

GiteaMirror commented

@257er commented on GitHub (Aug 30, 2024):

same issue here.

@257er commented on GitHub (Aug 30, 2024): same issue here.

GiteaMirror commented

@eeyrjmr commented on GitHub (Sep 10, 2024):

same, this only just started to be an issue

@eeyrjmr commented on GitHub (Sep 10, 2024): same, this only just started to be an issue

GiteaMirror commented

@eeyrjmr commented on GitHub (Sep 11, 2024):

I can't be sure but I think this started when I stopped using the gogit build of gitea... This was partially due to sha256
I will see if gogit windows build still works

@eeyrjmr commented on GitHub (Sep 11, 2024): I can't be sure but I think this started when I stopped using the gogit build of gitea... This was partially due to sha256 I will see if gogit windows build still works

GiteaMirror commented

@jonathanduke commented on GitHub (Sep 12, 2024):

The same thing has been happening to me recently. Since some of my pulls/pushes are automated to happen at night, it's a real pain.

I think it started after upgrading git-for-windows to 2.45.2.windows.1 and switching to GCM. A workaround has been discussed in the forums here:
https://forum.gitea.com/t/authentication-failed-for-but-running-the-command-again-works/8521

That does work to make it occur less often throughout the day if I set it to 24 hours vs. 1 hour, but it will still expire eventually. So, before my automated processes, I just made sure that I do an extra "git push" to force that expired token to be deleted, so the rest of the batch still works. That seems to get around the problem for now.

@jonathanduke commented on GitHub (Sep 12, 2024): The same thing has been happening to me recently. Since some of my pulls/pushes are automated to happen at night, it's a real pain. I think it started after upgrading git-for-windows to 2.45.2.windows.1 and switching to GCM. A workaround has been discussed in the forums here: https://forum.gitea.com/t/authentication-failed-for-but-running-the-command-again-works/8521 That does work to make it occur less often throughout the day if I set it to 24 hours vs. 1 hour, but it will still expire eventually. So, before my automated processes, I just made sure that I do an extra "git push" to force that expired token to be deleted, so the rest of the batch still works. That seems to get around the problem for now.

GiteaMirror commented

@lyleubben commented on GitHub (Sep 26, 2024):

Can confirm the same issue using git manually. Works on the second call. I believe this is also causing actions to fail on the checkout step.

@lyleubben commented on GitHub (Sep 26, 2024): Can confirm the same issue using git manually. Works on the second call. I believe this is also causing actions to fail on the checkout step.

GiteaMirror commented

@vansanper commented on GitHub (Oct 2, 2024):

Same issue here for my team, tried the workaround to see if it at least mitigates the problem to once a day...

@vansanper commented on GitHub (Oct 2, 2024): Same issue here for my team, tried the workaround to see if it at least mitigates the problem to once a day...

GiteaMirror commented

@bvandevliet commented on GitHub (Dec 9, 2024):

I also still face this issue. Quite annoying tbh.

@bvandevliet commented on GitHub (Dec 9, 2024): I also still face this issue. Quite annoying tbh.

GiteaMirror commented

@seepine commented on GitHub (Jan 22, 2025):

I want to know if there are any good solutions at present, such as rolling back the git-for-windows version? Or rolling back the gitea version?

@seepine commented on GitHub (Jan 22, 2025): I want to know if there are any good solutions at present, such as rolling back the git-for-windows version? Or rolling back the gitea version?

GiteaMirror commented

@eeyrjmr commented on GitHub (Jan 22, 2025):

I want to know if there are any good solutions at present, such as rolling back the git-for-windows version? Or rolling back the gitea version?

It would be rolling back git-for-windows to the version that used a windows specific solution.
This is extremely frustrating but we are dependant on git-for-windows to fix. There are several open issues on this over at that repository, using different forges

@eeyrjmr commented on GitHub (Jan 22, 2025): > I want to know if there are any good solutions at present, such as rolling back the git-for-windows version? Or rolling back the gitea version? It would be rolling back git-for-windows to the version that used a windows specific solution. This is extremely frustrating but we are dependant on git-for-windows to fix. There are several open issues on this over at that repository, using different forges

GiteaMirror commented

@Remmert-PBE commented on GitHub (Jan 23, 2025):

I got it working by prepending the username to the remote url, i.e. https://USER@git.company.intern/Organization/Product.git/. This prevents GCM from saving the login token with the dummy username 'OAUTH_USER'.

@Remmert-PBE commented on GitHub (Jan 23, 2025): I got it working by prepending the username to the remote url, i.e. `https://USER@git.company.intern/Organization/Product.git/`. This prevents GCM from saving the login token with the dummy username 'OAUTH_USER'.

GiteaMirror commented

@becm commented on GitHub (Feb 6, 2025):

It's a GCM issue, when it arbitrarily started to enforce OAuth when assuming a Gitea remote.

The issue is that token expiration dates are (still) not saved, so there is currently no other way than try and fail.
While other specialized providers for (e.g.) Azure and Bitbucket have some builtin ~~ways~~hacks to check this internally, there is no extra handling for the generic case.

Mitigations boil down to

just accept the 2nd try or
initially invalidate the OAuth config by setting credential.oauthAuthorizeEndpoint=// (not viable with 2FA) or
replace the git:https://<server> password entry with an application token
(no expiry issue and better access restriction)

@becm commented on GitHub (Feb 6, 2025): It's a GCM issue, when it arbitrarily started to enforce OAuth when assuming a [Gitea remote](https://github.com/git-ecosystem/git-credential-manager/commit/c512d1b0e7320ab2fc7cfac6fe1eafb90af0b273#diff-e79ea97a2573c4fff5ad878dd4a4e5df2b1a6a29c93d84b0ff5926f8de9ac3e3L12). The issue is that token expiration dates are ([still](/git-ecosystem/git-credential-manager/pull/1464)) not saved, so there is currently no other way than try and fail. While other specialized providers for (e.g.) Azure and Bitbucket have some builtin ~ways~hacks to check this internally, there is no extra handling for the generic case. Mitigations boil down to - _just accept the 2nd try_ or - initially invalidate the OAuth config by setting `credential.oauthAuthorizeEndpoint=//` (not viable with 2FA) or - replace the `git:https://<server>` password entry with an application token (no expiry issue and better access restriction)

GiteaMirror commented

@wantong commented on GitHub (Apr 3, 2025):

i am facing the same issue, as enable LDAP auth for gitea, my users need to push twice to get checkin work done. is there any progress one this problem?

@wantong commented on GitHub (Apr 3, 2025): i am facing the same issue, as enable LDAP auth for gitea, my users need to push twice to get checkin work done. is there any progress one this problem?

GiteaMirror commented