Skip to content
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

Authorization header removed after redirect #414

Closed
carlin-q-scott opened this issue Sep 9, 2013 · 8 comments
Closed

Authorization header removed after redirect #414

carlin-q-scott opened this issue Sep 9, 2013 · 8 comments

Comments

@carlin-q-scott
Copy link

I'm not sure if this is supposed to be a feature because my other custom headers were preserved. Accept-Encoding is doubled on the second request as well.

First Request:

GET http://mydomain HTTP/1.1
X-Intel-Loglevel: DEBUG
Accept: application/json
x-request-id: cd013990-c68f-450a-afb3-f5d31fef08b7
Authorization: my authorization
User-Agent: RestSharp 104.1.0.0
Accept-Encoding: gzip, deflate

First Response:

HTTP/1.1 302 Moved Temporarily
Location: https://mydomain

Second Request:

GET https://mydomain HTTP/1.1
X-Intel-Loglevel: DEBUG
Accept: application/json
x-request-id: cd013990-c68f-450a-afb3-f5d31fef08b7
User-Agent: RestSharp 104.1.0.0
Accept-Encoding: gzip, deflate,gzip, deflate
@haacked
Copy link
Contributor

haacked commented Sep 10, 2013

I believe this is by design of the HttpWebRequest class.

The Authorization header is cleared on auto-redirects and HttpWebRequest automatically tries to re-authenticate to the redirected location. In practice, this means that an application can't put custom authentication information into the Authorization header if it is possible to encounter redirection. Instead, the application must implement and register a custom authentication module. The System.Net.AuthenticationManager and related class are used to implement a custom authentication module. The AuthenticationManager.Register method registers a custom authentication module.

@haacked haacked closed this as completed Sep 10, 2013
@carlin-q-scott
Copy link
Author

I have a registered IAuthenticator that adds the authorization header. Since it is registered with RestSharp rather than HttpWebRequest I think it's the responsibility of RestSharp to register the authenticator with HttpWebRequest.

@haacked haacked reopened this Sep 10, 2013
@haacked
Copy link
Contributor

haacked commented Sep 10, 2013

Ah, ok. Would you be interested in taking a crack at fixing it and submitting a pull request?

@carlin-q-scott
Copy link
Author

I just stopped using the old URL. Most likely everyone does that. Until I find it necessary to use the redirect functionality I don't have any interest in fixing this.

I already looked into it a little bit and it looks somewhat complicated because while the interface for System.Net.IAuthenticationModule and RestSharp.IAuthenticator are close, they are not compatible.

@haacked
Copy link
Contributor

haacked commented Sep 10, 2013

I just stopped using the old URL. Most likely everyone does that. Until I find it necessary to use the redirect functionality I don't have any interest in fixing this.

Fair enough.

I already looked into it a little bit and it looks somewhat complicated because while the interface for System.Net.IAuthenticationModule and RestSharp.IAuthenticator are close, they are not compatible.

I have no idea what the rational is behind that. I bet a simple solution is just make the RestSharp implementation implement both interfaces.

But I'll close this for now until someone else feels it's important enough.

@haacked haacked closed this as completed Sep 10, 2013
@pauldbentley
Copy link

Hi,

I am experiencing this issue. I am using calling an API which by the nature of their implementation uses redirects for their "friendly-urls" to the actual URL. On the redirect the authorization is lost.

I'm not sure what the solution is?

Thanks

Paul

@carlin-q-scott
Copy link
Author

You can either use the unfriendly-urls or implement the fix suggested by Haacked and me.

@domenu
Copy link

domenu commented Jun 9, 2016

You can just assign a CredentialsCache object to the request in the Authenticate method.
Passing these credentials to a request indicates to the request that you allow them to be used, even for subsequent requests (redirects).

From this msdn article:

A CredentialCache will not be removed from the Credentials property when redirecting because WebRequest knows where you will allow your credentials sent. You may also reuse your cache by assigning it to subsequent requests.

So a RestSharp BasicAuthenticator implementation could look like this:


 public class BasicAuthenticator : IAuthenticator
    {
        private readonly string _baseUrl;
        private readonly string _userName;
        private readonly string _password;
        private readonly CredentialCache _credentialCache;

        public BasicAuthenticator(string baseUrl, string userName, string password)
        {
            _baseUrl = baseUrl;
            _userName = userName;
            _password = password;

            _credentialCache = new CredentialCache
            {
                {new Uri(_baseUrl), "Basic", new NetworkCredential(_userName, _password)}
            };
        }

        public void Authenticate(IRestClient client, IRestRequest request)
        {
            request.Credentials = _credentialCache;

            if (request.Parameters.Any(parameter =>
                            parameter.Name.Equals("Authorization", StringComparison.OrdinalIgnoreCase)))
            {
                return;
            }
            request.AddParameter("Authorization", GetBasicAuthHeaderValue(), ParameterType.HttpHeader);
        }


        private string GetBasicAuthHeaderValue()
        {
            return string.Format("Basic {0}",
                            Convert.ToBase64String(Encoding.ASCII.GetBytes(string.Format("{0}:{1}",
                                _userName, _password))));
        }
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants