You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to set up a gitea instance on a small GCP VM running an Apache reverse proxy behind IAP. The instance works fine through browser workflows, but needed access through Git CLI. I installed and set up git-remote-https+iap per the readme, but kept getting 401s (verified that they originated from IAP; the apache server never saw these requests) when trying to clone a test repo. TL;DR: I was able to fix the problem by removing the audience field from the POST to exchange the refresh token for an authorization. I was finally clued in to this because manually following the OAuth workflow in the GCP docs for Authenticating from a Desktop App worked fine, and they do not include the audience in the refresh request.
I do not know enough about OAuth to know if this problem was due to an API change, a misconfiguration in IAP on my part, or if I'm abusing the software. So I wanted to open this issue to figure out if code changes are warranted, and what behaviors should be supported. I'm happy to submit a PR if someone wants to advise on whether the audience parameter should be configurable, and the best way to expose that configuration. Or, I'd be even happier to let someone else just take care of it. OR, if I've misconfigured my proxy, I'd appreciate any advice there as well.
Note that removing the audience parameter likely obviates the need for storing the service OAuth clientID in the git config.
Expected Behavior
IAP authorizes git traffic to my server
Actual Behavior
IAP returns 401 Unauthorized.
Steps to Reproduce the Problem
Set up IAP on a global HTTPS load balancer in GCP (Console).
Create Desktop client OAuth credential (Console).
Enable new Desktop credential for programmatic access to load balancer backend service per docs (gcloud CLI)
set up git-remote-https+iap per README
git clone https://myserver.com/myrepo.git
fatal: Authentication failed for 'https://myserver.com/myrepo.git (due to 401 returned by IAP)
Specifications
Version: 0.3.4
Git version: 2.47.0.windows.1
Operating System: Win10 22H2 19045.5131
The text was updated successfully, but these errors were encountered:
I've been trying to set up a gitea instance on a small GCP VM running an Apache reverse proxy behind IAP. The instance works fine through browser workflows, but needed access through Git CLI. I installed and set up git-remote-https+iap per the readme, but kept getting 401s (verified that they originated from IAP; the apache server never saw these requests) when trying to clone a test repo. TL;DR: I was able to fix the problem by removing the
audience
field from the POST to exchange the refresh token for an authorization. I was finally clued in to this because manually following the OAuth workflow in the GCP docs for Authenticating from a Desktop App worked fine, and they do not include the audience in the refresh request.I do not know enough about OAuth to know if this problem was due to an API change, a misconfiguration in IAP on my part, or if I'm abusing the software. So I wanted to open this issue to figure out if code changes are warranted, and what behaviors should be supported. I'm happy to submit a PR if someone wants to advise on whether the audience parameter should be configurable, and the best way to expose that configuration. Or, I'd be even happier to let someone else just take care of it. OR, if I've misconfigured my proxy, I'd appreciate any advice there as well.
Note that removing the audience parameter likely obviates the need for storing the service OAuth clientID in the git config.
Expected Behavior
IAP authorizes git traffic to my server
Actual Behavior
IAP returns 401 Unauthorized.
Steps to Reproduce the Problem
git clone https://myserver.com/myrepo.git
fatal: Authentication failed for 'https://myserver.com/myrepo.git
(due to 401 returned by IAP)Specifications
The text was updated successfully, but these errors were encountered: