I am sure this is not a new issue I am facing, but couldn't find any resolution yet.So, we have a ng2 app which uses Windows Authentication. It is implemented using Waffle libraries with Jersey RESTful service. We are implementing logout functionality, which seems to have an issue where browser is caching credentials, until all of it’s instances are closed.
When user launches browser for the first time (first instance of browser), it prompts for credentials as expected. When user clicks on “Logout” option from application, session is invalidated on server. But, next time when user refreshes URL or launches application in new tab, browser do not prompt for credentials.
In Internet Explorer, using document.execCommand(“ClearAuthenticationCache”) clears credentials stored for the user. Is there any equivalent code or way to clear http authentication cache from Chrome?
Related
I have a web application that opens a local application on client machines using a protocol already registered during client setup.
The web application gives an alert when opening local application and gives a checkbox to be selected in that alert. If checkbox is checked, the browser doesn't prompt next time when opening the local application.
However, this checkbox is seen when my web application is hosted with https. When hosted with http, the checkbox is not given by the browser and the browser always throws the alert. Can the user at client side manually do something to avoid the alert every time?
I looked into the Google chrome settings. There is Protocol Handlers in Site Settings but it doesn't allow to enter a site manually. It shows outlook.office.com which I can remove but doesn't give a way to enter a site manually.
Is there a workaround to trust a site and not show alert for this specific trusted site
If your environment is Microsoft, with a GPO the website can be added in the safe list address of Internet Explorer options. Otherwise, you will have to do it manually in each endpoint.
I'm debugging requests to a web application. The app automatically logs me in every time, as Chrome sends my client certificate and I am recognized by it. However, I need to log in as a different user. Unfortunately, when I log out, the app automatically logs me in again immediately, as it recognizes my client certificate.
Therefore, I want to temporarily disable sending my client certificate when establishing the secure connection. Is there a setting in Chrome debugger or an extension or a setting in the OS settings? I could not find anything. Also Googling did not help.
I am automating a webapplication which uses windows authentication to sign-in.
I am using selenium specflow c# and running my tests on teamcity which uses grid in turn on the build agent.
However each of my row in Examples under scenario outline is testing with a different user.
We are using before scenario hook to create the Remote webdriver instance which is context injected to all the step bindings. However, at this point it is assuming that the user is the logged in user on the hub .
If I am using hub/grid, I am able to test with only one user login as the website takes the user credentials of the logged in user on the hub.
To work around this, we have used credentials embedded in the url. This happens in the Given step much after the hooks run.
While Chrome stopped the support for url credentials, how do I impersonate the users logging into the browser connected via remoteweb driver.
I have explored using process to create webdriver process and passing the credentials. I am not sure if this is the right way.
Or how do I make Chrome prompt for user credentials and stop auto logging as the hub user.
Because of this we are unable to upgrade the Chrome version.
I have explored so much but did not find a conclusive solution.
Regards,
Vijaya
How to revive HttpClient and make it see that the network is available again without fully restarting the application?
In case when a Xamarin.Forms app was launched with no network connection available and then later network connection is enabled, HttpClient.SendAsync(request) throws NameResolutionFailure and it does not recover, no matter how many times the request is repeated.
It seems, HttpClient does not know how to recover when network connection appears.
To reproduce the issue in Android emulator:
ensure your app is completely closed
turn network off (set Data status to Roaming in emulator settings or use the status bar to toggle the data or LTE switch).
launch your app, run a web request to verify that it does not work (obviously, you will need try/catch around the web request to avoid crashing)
while the app is still open, enable the network
run a web request - will get NameResolutionFailure
only full application restart will revive HttpClient
The issue does not happen if I use domain names specified in etc/hosts file.
I tried to fully recreate HttpClient and resend a new request when the issue occurs, but that does not help. Only full restart of the app helps.
Obviously, I cannot ask user to fully kill my app and start it again every time when user has turned on his network connection after launching my app.
This is a known issue. See:
Mono: https://bugzilla.xamarin.com/show_bug.cgi?id=45761
iOS: https://bugzilla.xamarin.com/show_bug.cgi?id=45763
Android: https://bugzilla.xamarin.com/show_bug.cgi?id=45383
The workaround is to manually set the DNS refresh:
System.Net.ServicePointManager.DnsRefreshTimeout = 0;
I want to build a Chrome App to listen notifications sent by my Lab, and I don't want to open a Chrome window(just let the app run in background silently, and pop a box when I have a new message). But sockets api is only for packaged app, and packaged app has no background permission, what should I do? Thx.
(Quick answer, will edit later with more info.)
Chrome Packaged Apps don't need that permission, they have a background page by default. Most (say, 99% of existing) chrome apps will open a window when they launch, but thats optional.
If your app has an open window, the runtime will keep your application running an not move into an idle state. However, if you are using certain APIs, such as having an open TCP server socket listening for incoming connections, its very unlikely that the runtime will shut your app down unless the system is under serious constraints.