How to disable webview cache for Windows Phone 8.1 Runtime universal app? - caching

Is it possible to disable cache for the Webview control for a Windows Phone 8.1 runtime universal app? My App seems to be remembering the information it received the first time. My app logs me into a service and when I go back to rerun app in the emulator (without completing shutting down the emulator) it logs me in automatically rather than giving me the prompt. This behavior is in the NavigationCompleted handler if that helps explain a bit more on where I am hitting this issue.
If I were to shut off the emulator completely and then restart it then I am prompted for the login name and password again. I have gotten over this cache issue, when I was using the HttpClient in other part of my app, by sending the no-cache in the header as:
client.DefaultRequestHeaders.Add("Cache-Control", "no-cache");
Can I do something similar for the webview control?
Thank You!

here is the code which I used to clear the cookies which resolved my issue:
Windows.Web.Http.Filters.HttpBaseProtocolFilter myFilter = new Windows.Web.Http.Filters.HttpBaseProtocolFilter();
var cookieManager = myFilter.CookieManager;
HttpCookieCollection myCookieJar = cookieManager.GetCookies(new Uri("target URI for WebView"));
foreach (HttpCookie cookie in myCookieJar)
{
cookieManager.DeleteCookie(cookie);
}

There is no way to do it programmatically.
But for the test purposes for Windows application you can do it manually - http://blogs.msdn.com/b/wsdevsol/archive/2012/10/18/nine-things-you-need-to-know-about-webview.aspx#AN7.

Related

ASWebAuthenticationSession in MacOS 10.15 (Catalina)

I am trying to implement the new ASWebAuthenticationSession in MacOS 10.15 and I'm getting a bit confused about the callbackURLScheme.
The header file for ASWebAuthenticationSession says:
The callback URL usually has a custom URL scheme. For the app to
receive the callback URL, it needs to either register the custom URL
scheme in its Info.plist, or set the scheme to callbackURLScheme
argument in the initializer.
So I initialize like this:
self.webAuthSession = [[ASWebAuthenticationSession alloc] initWithURL:self.authURL
callbackURLScheme:#"myurlscheme://"
completionHandler:^(NSURL * _Nullable callbackURL, NSError * _Nullable error) {
}];
The oauth provider I am trying to access, does not support custom URL schemes, so I have it set to redirect to a web address which in turn redirects to my URL Scheme.
So, after clicking Login in my MacOS app, Safari presents a window that allows me to login to the service. After successfully logging in the redirect happens but the web page just goes to a screen saying
Safari can't open the specified address.
I can see that the address is myurlscheme://?code=1234567890abcdefgetc... which is correct but it's obviously not calling the ASWebAuthenticationSession callback.
If I add the URL Scheme to the plist, then the safari window shows a prompt asking if you want to open it in the my app.
I know I can then fetch the code from the App Delegate's application:openURLs: method, but this is fiddly, has an unnecessary prompt for the user to click, and also leaves the ASWebAuth... safari window open. This should all be automatic through the callback.
The only way I get the callback to fire, is by closing the safari window in which case it calls back with error.
I have just returned to this to try again and it seems to be working fine on MacOS 10.15.1 and 10.15.2 beta.
I have noticed that the callbackURLScheme parameter must not include ://
I'm not able to go back and test it again on 10.15 but i'm happy to use this now assuming everyone on 10.15 would have updated to 10.15.1
Darren is right in MacOS you must remove the :// from the callbackURLScheme. iOS works fine no matter if you :// or not. However, in MacOS Catalyst there seems to be a bug. My app is getting focused once I login, but isn't getting the callback. Haven't found a way to fix it yet.

Xamarin.Auth - Google authentication won't open in browser

I'm trying to do authentication on my Android application using Xamarin.Auth. Some time ago, Google made the policy that you cannot do this in an embedded web view (for totally valid reasons).
I'm trying to open the account authentication page in a browser, but keep getting the embedded web view. I understand that isUsingNativeUI needs to be true in the following code:
_auth = new OAuth2Authenticator(clientId, string.Empty, scope,
new Uri(Constant.AuthorizeUrl),
new Uri(redirectUrl),
new Uri(Constant.AccessTokenUrl),
null,
isUsingNativeUI = true);
At every point in my application, this always equals true.
Elsewhere, I have code that redirects to what should be a browser:
var authenticator = Auth.GetAuthenticator();
Intent intent = authenticator.GetUI(this);
this.StartActivity(intent);
Regardless, I keep getting a dreaded 403 disallowed_useragent error whenever I try to run the project. Is there another element to this that I'm missing?
To my knowledge, setting auth.IsUsingNativeUI = true in the constructor should dictate that it must open in a browser. I've been following this example to try and debug with no success. I even pulled the guy's repo down to my machine and ran it - the Intent variable at the moment of redirection is almost identical.
Could there be something stupid that I'm missing? What else might be going wrong?
I realize this is an old question, but I had the same issue.
You have to install version 1.5.0.3 of the Xamarin.Auth Nuget package. The newest one (version 1.7.0 right now) doesn't work. You'll have to also install the PCLCrypto nuget package in order to get that version to work.

Accessing Webapi on Localhost on Dev Machine from Android Emulator

This may well be a duplicate question, but no answer from an existing question has solved my problem.
I have a WebAPI end point running on my dev machine. I've configured it to run on
.UseUrls("http://localhost:57971", "http://10.0.2.2:57971", "http://192.168.44.1:57971", "http://192.168.1.48:57971", "http://*:57971")
where:
192.168.44.1 is Desktop Adapter #2 on the emulator Networks settings tab
10.0.2.2 is the special address for the Android emulator, as set out in Google's doco (possibly not relevant to Xamarin) and
192.168.1.48 is my local IP address for my dev machine.
I have created a firewall rule permitting connections on TCP port 57971.
I researched this pretty heavily and heeded instructions such as those set out here http://briannoyesblog.azurewebsites.net/2016/03/06/calling-localhost-web-apis-from-visual-studio-android-emulator/
I'm kinda out of ideas. The annoying thing is, it fails silently. There is no exception and the output just basically shows the different threads exiting with code 0. And the application keeps running i.e. the debugging session is not returning the IDE to a "code entry" state. This may suggest that something else its at play here.
The code looks pretty innocuous to me:
protected async Task<T> GetAsync<T>(string url)
where T : new()
{
HttpClient httpClient = CreateHttpClient();
T result;
try
{
var response = await httpClient.GetStringAsync(url);
result = await Task.Run(() => JsonConvert.DeserializeObject<T>(response));
}
catch
{
result = new T();
}
return result;
}
I'm using Visual Studio 2015.
I'm using the Visual Studio emulator https://www.visualstudio.com/vs/msft-android-emulator/
Any idea how I can get wheels on the ground on this thing?
Is there a way to Ping my machine from the emulator?
Thanks
I got this working by using 169.254.80.80 i.e. I added it to the list of urls which the API serves and called that ip address from the Xamarin app.
So, in Program.cs became simple:
.UseUrls("http://localhost:57971", "http://169.254.80.80:57971")
I also had to add it to the bindings element ApplicationConfig file in the hidden .vs folder of the ASP.NET API solution. Not sure why it had to be 169.254.80.80, as that was Desktop Adapter #4.
That got it working.

Vaadin session expired immediately

I have a simple vaadin application created from an achetype. The page with button is loaded but when you click it, session is already expired. This problem occurs just only under this conditions:
session is https
browsert is IE 11.0.14393.0 (after Windows 10 Aniversary Update 1607)
SPNEGO is used
Server is WildFly 10.1.0.Final
Other browsers (EDGE, Firefox, Chrome) works fine. Before Aniversary update the IE 11 worked as well.
I know it is not enough information but I don't know what can be important. Can you point me what should I check / should I do?
I haven't find anything strange at logs and communication. I'm guessing there will be something wrong with a session but I can not find what is bad :-(
The problem is caused by the internally generated request for favicon. This request is generated internally by IE and uses wrong session ID (jsessionID). Server creates a new session and answers with its ID. Unfortunately the IE then uses this new session ID for other requests. Other browsers (and previous IE version) correctly use the original jsessionID and do not the one that is returned as a response to the internally generated favicon request.
Solution: I have changed the favicon links within my application and pointed them outside of the secured server area.
#Override
public void modifyBootstrapPage(BootstrapPageResponse response) {
// FIX for IE11 at Windows 10 after anniversary update
response.getDocument().head().getElementsByAttributeValue("rel", "shortcut icon").attr("href", "/static/favicon.ico");
response.getDocument().head().getElementsByAttributeValue("rel", "icon").attr("href", "/static/favicon.ico");
}

Watin accessing localhost

When executing the c# code in MSTest involving WatiN
var browser = new IE("http://localhost:56034/");
The web page is displayed in IE but after about a minute, I receive the error
Timeout while waiting for main document becoming available with the error message
Timeout while waiting for main document becoming available
The code
var browser = new IE("http://www.bing.com/");
works fine.
I am running IIS Express 7.5. Since I am new to the WatiN I am hoping that I am missing something simple.
Following the advice in http://spin.atomicobject.com/2010/12/15/watin-and-com-errors-enable-ie-protected-mode-for-local-intranet-zone, turning ON protected mode for the intranet zone in IE 8 solved the problem.

Resources