-
Notifications
You must be signed in to change notification settings - Fork 21
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
Redirects cause mutual authentication to fail #12
Labels
Comments
Analysis conducted by the requests-kerberos folks suggests this is inherent in the requests model. Unfortunately I'm not aware of anything that makes our codebase different in this regard. It's probably best to turn off mutual authentication here. This shouldn't be any risk if you're over TLS already. |
ernestask
added a commit
to abrt/retrace-server
that referenced
this issue
Oct 7, 2019
This also explicitly disables mutual authentication, which seems to be causing issues with redirects to /start and friends. Context: https://fedoraproject.org/wiki/Changes/kerberos-in-python-modernization requests/requests-kerberos#64 pythongssapi/requests-gssapi#12 pythongssapi/requests-gssapi@498da2e Fixes #263 Signed-off-by: Ernestas Kulik <ekulik@redhat.com>
mkutlak
pushed a commit
to abrt/retrace-server
that referenced
this issue
Oct 7, 2019
This also explicitly disables mutual authentication, which seems to be causing issues with redirects to /start and friends. Context: https://fedoraproject.org/wiki/Changes/kerberos-in-python-modernization requests/requests-kerberos#64 pythongssapi/requests-gssapi#12 pythongssapi/requests-gssapi@498da2e Fixes #263 Signed-off-by: Ernestas Kulik <ekulik@redhat.com>
Closing since mutual auth is disabled by default now, and I can't do anything else about it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have a server that issues a redirect, to another page (Eg, Gitlab EE has a specific page to handle authenticating Kerberos and creating a session), requests-gssapi will attempt to authenticate both the original 302, and the page that is returned. This will either cause a failure because the context is already complete, or a failure because the second page doesn't process the challenge and return another token.
This appears to be related to requests/requests-kerberos#64
The text was updated successfully, but these errors were encountered: