Visitar URL original
http proxy negotiate/gssapi authentication? · Issue #83 · requests/requests-kerberos · GitHub
Skip to content

http proxy negotiate/gssapi authentication? #83

Closed

Description

@benley

I was hoping to find a HTTPProxyKerberosAuth class to enable working with http proxies that require NEGOTIATE gssapi auth, like certain configurations of squid. Is there a way to use requests-kerberos handle that scenario as it currently stands?

This would be akin to HTTPProxyDigestAuth from requests-toolbelt, if the necessary code doesn't already exist somewhere.

Activity

  1. Lukasa commented on Oct 23, 2016

    @Lukasa
    Member

    requests-kerberos cannot currently handle that kind of authentication.

  2. benley commented on Oct 23, 2016

    @benley
    Author

    Thank you for clarifying. Is it proxy auth something that belongs in this project, or am I barking up the wrong tree?

  3. Lukasa commented on Oct 24, 2016

    @Lukasa
    Member

    It definitely belongs in this project. =) Unfortunately, I have very little time to tackle writing such a thing, so I'll have to leave this open to someone else who can find that time.

  4. carsonyl commented on Oct 24, 2016

    @carsonyl
    Collaborator

    This would be nice to have! However, Requests doesn't support multiple auth handlers, so it can be a problem if you want to use one auth method for the proxy, and another for the actual request. This is already an issue with HttpNtlmAuth from requests-ntlm, though I don't know if the problem's tracked anywhere.

    HttpNtlmAuth also handles NTLM authentication for either a proxy or a website, based on what response header it sees first, which makes it a bit of an oddball.

  5. NurcanSonmez commented on Jan 3, 2019

    @NurcanSonmez

    Hi everyone! Any ideas how the proxy auth can be done with requests-kerberos?
    It's been a while since this ticket is opened, just wanted to check.

  6. NurcanSonmez commented on Jan 9, 2019

    @NurcanSonmez

    When I use IP address as the auth surrogate in the proxy the following works, however, when I use no surrogate it doesn't work. Just sharing the code in case it'll help others.
    import requests from requests_kerberos import HTTPKerberosAuth, REQUIRED
    PROXY = {'https': 'http://yourproxy:80'}
    s = requests.Session()
    response = s.get("http://yourproxy:80",auth=HTTPKerberosAuth(force_preemptive=True))
    response_cnn = s.get("https://www.cnn.com", proxies=PROXY, verify=False, headers={"Proxy-Authorization": response.request.headers['Authorization']})

  7. nametkin commented on Mar 21, 2020

    @nametkin

    @NurcanSonmez , Thanks for your code, it was very useful for me when I just ran into this problem. But with requests https, it really doesn't work. Having studied the code of Requests, I realized that the authentication data (that was placed in the request header) does not reach the method "set_tunnel" (module httplib(py2)/http.client(py3)). I used the following code to solve this problem:

    import requests
    from requests_kerberos import HTTPKerberosAuth
    from urllib3.util import parse_url
    
    class HTTPAdapterWithProxyKerberosAuth(requests.adapters.HTTPAdapter):
        def proxy_headers(self, proxy):
            headers = {}
            auth = HTTPKerberosAuth()
            negotiate_details = auth.generate_request_header(None, parse_url(proxy).host, is_preemptive=True)
            headers['Proxy-Authorization'] = negotiate_details
            return headers
    
    session = requests.Session()
    session.proxies = {'http': 'http://yourproxy:proxyport', 'https': 'http://yourproxy:proxyport'}
    session.mount('https://', HTTPAdapterWithProxyKerberosAuth())
    
    response = session.get(r"https://www.google.com/")
    

    Maybe it will be useful for someone.

  8. jborean93 commented on Nov 29, 2021

    @jborean93
    Contributor

    Support for proxying http endpoints has been added with #148. As mentioned above using this for https endpoints is not supported due to limitations with the underlying libraries that are used. Until this is fixed we can only offer support for http endpoints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions