-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with auth bearer token validation (unreleased) #177
Comments
Hi, Thanks! |
Thank you for the quick response.! It did not fix the issue but it did lead me to figure out the core issue and a workaround. The real issue is here: In our deployment, we have I think in order for it to work, the check would have to go a bit further before assuming we are in the weaviate/openid state. A working, if inelegant, example is below. That said, removing the That said, I believe something like this would be a potential solution by validating the response is JSON. There is probably a better way to validate the response though.
|
alright interesting :) |
Yes, that works thanks! However, one complication: there is a known issue with Maybe something like this is needed?
|
I will mention a possible regression though: if I try to give a URL without the headers, I previously got:
I now just get a JSON decode error as this isn't caught. I'm fine with that but I thought I would mention it |
I think that was an artifact of your proxy. Before it would just check if the OIDC config returns a 200 status code to determine if you need authentication, now it also checks if it can decode it. So I think this is working as intended |
Thanks for letting me know, what an annoying design of the requests library. I added your codesnippet |
Yes I agree that it was an artifact of our proxy. Thanks so much for responding to this quickly! |
You're welcome! There was a tiny change during review with the Json_Exception, would be great if you could double check, but I tested with simplejson installed and without |
I was looking into oauth-related things and noticed there were some recent commits that haven't been released that break our workflow.
In our use case, we are using an
oauth2-proxy
that sits outside of weaviate. That is, weaviate itself knows nothing about authentication and it happens at the nginx ingress layer.We had previously would get a token and use it like this:
client = weaviate.Client(URL, additional_headers= {"Authorization": f"Bearer {token['access_token']}"})
It seems that this now breaks. I think it is due to this line:
https://github.com/semi-technologies/weaviate-python-client/blob/main/weaviate/connect/connection.py#L94
Since we aren't using weaviate's auth, the validation here will fail.
Is it possible to remove this validation or make it optional?
The text was updated successfully, but these errors were encountered: