Reputation: 3129
I am having an issue where an app tries to access resources from the same server using different authentication methods, the two methods are:
The HttpBaseProtocolFilter
is setup to:
Code
HttpBaseProtocolFilter filter = new HttpBaseProtocolFilter();
filter.CacheControl.WriteBehavior = HttpCacheWriteBehavior.NoCache;
filter.CacheControl.ReadBehavior = HttpCacheReadBehavior.MostRecent;
filter.AllowUI = false;
If the resource needs credentials then I use:
filter.ServerCredential = new PasswordCredential(
RequestUri.ToString(),
UserName,
Password);
HttpClient httpClient = new HttpClient(filter);
If the resource needs a Bearer token I use:
HttpClient httpClient = new HttpClient(filter);
httpClient.DefaultRequestHeaders.Authorization = new HttpCredentialsHeaderValue("Bearer", token);
The ServerCredential
are null
filter.ServerCredential = null
using(httpClient)
{
using(HttpRequestMessage requestMessage = new HttpRequestMessage(new HttpMethod(method), RequestUri))
{
using(HttpResponseMessage response = await httpClient.SendRequestAsync(requestMessage))
{
// Do something with response
}
}
}
If the HttpClient
request returns a 200 (OK) using ServerCredential
, then every following Bearer
request also returns 200 (OK) even if the Bearer
token is invalid and filter.ServerCredential
is null.
It looks as if the filter.ServerCredential
is cached and all subsequent calls are authenticated with the cached credentials.
I have to restart the app if I want to do a Bearer
authentication.
How can I remove, disable or clear the ServerCredential
of the Windows.Web.Http.HttpClient?
Things I've tried:
var cookieManager = filter.CookieManager;
HttpCookieCollection myCookieJar = cookieManager.GetCookies(RequestUri);
foreach (HttpCookie cookie in myCookieJar)
{
cookieManager.DeleteCookie(cookie);
}
The myCookieJar
is empty.
PasswordCredentialPropertyStore
Windows.Security.Credentials.PasswordCredentialPropertyStore credentialPropertyStore = new Windows.Security.Credentials.PasswordCredentialPropertyStore();
The credentialPropertyStore
is empty.
AND
PasswordCredentialPropertyStore
's method Clear is reserved for internal use and is not intended to be used in your code.
Any ideas?
Upvotes: 13
Views: 4869
Reputation: 76
This issue has now been resolved and the fix is included in the //build 2016 version of the SDK. There are two parts to this fix:
In Windows build 10586 onwards, new credentials can overwrite older cached values in the same app. So, if you were using an instance of HttpClient c1 with (userA, paswordA), and then created a new client instance c2 with (userB, passwdB) in the same app: this should work. The new credentials overwrite the old cached ones (this would not work in earlier versions).
However, #1 is still not sufficient to let you clear the original cached credentials - you can only overwrite them. To support clearing of cached credentials, we have now added a method to HttpBaseProtocolFilter - HttpBaseProtocolFilter.ClearAuthenticationCache() which clears all cached credential information. You can call this when you want to clear the credentials and/or client certificates from past instances of HttpClient in your app. The documentation for this method will soon be available here
Thanks Sidharth
[Windows Networking team]
Upvotes: 1
Reputation: 11
Just append
uwp_bugs_never_got_fixed={something never repeat}
in your request URL query parameters.
Upvotes: 1
Reputation: 11
For whomever is facing this issue ;
I had the same issue with Basic Credentials on a UWP Phone app ; Once a user got authenticated succesfully once, it cached those credentials. Even when closing the app, even when restarting the phone. I honestly suspected a bug on the server end or so, but there was a similar App which worked as expected against the same server.
I found that adding :
filter.CookieUsageBehavior = HttpCookieUsageBehavior.NoCookies
solved my issue. When entering proper credentials all was fine, when retrying with false credentials authentication failed. Exactly as it is supposed to do !
Upvotes: 0
Reputation: 76
Thanks for reporting this issue. This is a known behavior in the low level WinINet HTTP stack that sits underneath the Windows.Web.Http.HttpClient API in the operating system. Once an HTTP request succeeds, the credentials are cached in the process memory for that app. Hence, even if you create a new HttpClient instance and set different credentials into the HttpBaseProtocolFilter, the same (original) credentials apply and will be used as long as they continue to be valid on the server side. (If the cached credentials stop being valid on the server side, they will be overwritten with the newly supplied ones.)
We are aware of this issue and are working on correcting it by allowing the clearing of cached credentials. Unfortunately, the only workaround currently is having the user restart the app which will clear the process memory for the app. That will allow a different credential to be used at first. However, that credential will also 'stick' for the remainder of the application process as long as it is valid on the server.
Thanks,
Sidharth Nabar [Windows Networking team]
Upvotes: 3