Closed schmidp closed 1 year ago
Hi @schmidp,
I think this is same problem like mentionned in this issue : #3783
Indeed cookie received (id_token) from your oidc provider are greater thant 4096 char (contain too much, roles, groups...) I think authentification management was changed and now cookie are store in the web browser.
If id_token cookie are greater than 4096 char webrowser remove this cookie from request to respect RFC that why the error message from weave-gitops is : {"error": "http: named cookie not present"}
We are working on a fix for this (replacing the direct cookie with a Session token instead).
@schmidp Have you set the OIDC verifier URL to https://accounts.google.com ?
@schmidp Have you set the OIDC verifier URL to https://accounts.google.com ?
yes
clientID: zzzz.apps.googleusercontent.com
clientSecret: yyy
customScopes: email,profile
issuerURL: https://accounts.google.com
redirectURL: https://xxxx.com/oauth2/callback
@schmidp The error message in the text above is Your client does not have permission to get URL /oauth2/v3/certs
is the client id and secret correct?
@bigkevmcd Yes, I have just rechecked it and its correct. Also it worked before I did the helm uninstall/install without changing the k8s secret in between.
@schmidp We are working to fix an issue where if the OIDC ID token results in cookie that is bigger than 4096 bytes, the browser drops it and we get that http: named cookie not present
.
But this behaviour hasn't changed recently, could it be the case that you have a lot of groups which would be pushing the cookie beyond this size?
@schmidp We are working to fix an issue where if the OIDC ID token results in cookie that is bigger than 4096 bytes, the browser drops it and we get that
http: named cookie not present
.But this behaviour hasn't changed recently, could it be the case that you have a lot of groups which would be pushing the cookie beyond this size?
Yes that is possible, I have a lot of groups. Maybe the helm install/uninstall is just a coincidence.
So today the problem resolved itself. I swear by my liver, I did not change any config and no redeployment. We also did not change any groups or added removed me from groups. So either the helm install/uninstall changed something that was cached somewhere or google changed something or its just magic.
@schmidp Thanks for letting us know, we will push on with the session implementation which would solve large groups cookies, but otherwise, seems like it's working for you.
I had the same issue just happen on our deployment. It had been running for about 17 days, and started getting the same cookie not present error. Restarted the deployment and it went away.
We have now released support for session storage, which removes the ID token from the cookie.
https://github.com/weaveworks/weave-gitops/releases/tag/v0.31.2
I'm going to close this now, but feel free to reopen if it's not working.
Describe the bug
I have GitOps deployed with flux and integrated it with google OIDC and it worked fine. I was able to login with my google account and watch flux do its thing. Then I was restructuring my flux repo layout and moved the GitOps deployment from one Kustomization to another. So basically flux did a helm uninstall and then an install, if I am correct. Also the namespace stayed the same.
But after the reinstallation I can no longer login via OIDC. The helm chart and all its config values stayed the same.
In the browser I get the following message:
In the logs I can see:
Helm:
Environment
To Reproduce Steps to reproduce the behavior:
see above.
Expected behavior
I can login with OIDC.
Actual Behavior
I get the error message above.
Additional Context (screenshots, logs, etc)