I have the following case in a web application of mine. The usual browser that the user uses is Chrome.
I use digital certificates that users have cryptographic cards that they insert into a card reader.
To log in to the application, basically users access the https link that makes the certificate data read.
So far everything works fine.
If the user to end his session of the application closes the browser, there is no problem. Everything is over.
But if the user wants to leave his application session, without closing all browser windows, here are my problems.
There is a button that closes the session of the application, the user leaves and redirects to the initial login screen. It seems that everything has been reset, because the user has left. But when the new user wants to log in and press the link to read the certificate data, instead of doing a new reading of the new card, use the data from the previous card without just asking for the pin to access it.
The problem goes further, for example, if the user has forgotten the card, the card and tries to logarize, the failure to read the certificate. But now, although inserted correctly, the card will not be read again until the browser is restarted, which maintains a cache that does not have a certificate.
At the moment only the solution was found by closing all Chrome windows, but that depends on whether the user does or not.
A partial solution would be sure to close the browser with javascript () but for some time, it can not be closed with javascript (window.close ()), a window that can not be opened from the site itself, with what is available I think it's ruled out
Can someone contribute to me? Thank you
Chrome and the rest of browsers maintain a cache of the SSL authentications performed and decide when to prompt user for selecting a certificate. There is no "logout" function neither the connection can be closed from server side due to TLS resumption protocol ( client can resume the session)
This a common and known issue when defining an authentication system using client certificates. I only have found a workaround: use different domains to force browser to choose a certificate:
login.domain.com
-->login1.domain.com
-->login2.domain.com
-->loginN.domain.com
You have a virtual authentication URL login.domain.com which redirects user's browser to a random loginN.domain.com every time you need an authentication. Chrome will detect that it is a different domain and will prompt user for selecting a certificate
You could also think about using different ports instead of different DNS, but then you could have problems with the user's firewall because you are not using a standard port, and in this case Firefox does not show the window either.
Related
Please I developed my mobile app and is primarily using localStorage for storing account info and some other info. The app has mobile and browser version.
For the browser version, I expect a user that is logged in to not be redirected to an auth page on browser restart. This works fine as my info are stored in localStorage. On the other hand, my mobile doesn't. User have to log in whenever he restart the app.
Please what option do I have? What option do developers use for the mobile storage? Do I have to use database? If so which one should use and where can I find a better documentation on this topic?
Note: I am using Cordova for my mobile app development framework.
For some reason, localStorage is tied to browser history. Some mobile browsers have an option to erase browser history on exit. If that box has a checkmark in it, then localStorage gets purged along with browser history everytime the browser is closed! So, you can ask the user to go into Settings and uncheck that box. Note: localStorage is not supported by older IE browsers, Opera Mini, and some Blackberry devices.
If cookies are enabled, you could use a one-time cookie code to log the user in automatically, but that cookie must expire after first use. Once the user is logged in, the server must issue a new cookie code to the client. And the client can use that new cookie to log in once again or keep alive the session. Using the same cookie twice should not work for security reasons. And the server must make sure never to issue the same code to two different users!
I remember, about 10 yrs ago, I went online to check my emails, and immediately the site had me logged into another user's account! I could have read that person's private emails and stuff, but I decided not to. I reported the incident to the admin. The problem was probably their server issued a random quick-login access code to me, and another user somehow got the same access code that I got. And when I opened the website, it thought that I was that other person. If your site deals with money and credit cards, you should avoid this technique! Any kind of auto login is a bad idea for a bank!
There is a plug-in to store data in an SQLite database using Cordova in this link
. You can find more details about storage with Cordova in the doc.
Save your data by using the following:
localStorage.setItem("variable", value);
Retrieve it from localstorage by using the following:
localStorage.getItem("variable");
It is as simple as it is.
Reference here.
Chrome is auto-filling the credentials, but not log me in until I click login. How to automate? (windows, non-google websites).
Using the Chrome Identity API you can have Chrome (on desktop and Android) automatically attempt to log in the user when they hit your page, even if their session has expired.
Following is a workflow diagram of how it works, but the details can be found in the Google Authentication API: Let the user automatically sign back in section:
It is not the browser's responsibility to auto-login to websites. This is the responsibility of the website you are accessing. The browser can remember form data and auto-fill for you, as can various extensions like LastPass.
However, in order to actually auto-login, you must first login to the website you are trying to access and enable the option they provide, often called 'Remember me?'. The website would typically use a cookie to store the credentials (securely with a hash + salt), and if the cookie still exists (not cleared from the browser or expired), and the hash of real password in database matches the one in the cookie, the website will auto-login.
You could force the browser to try and auto-login with extensions, which are essentially macros. You could try Auto Login or iMacros extensions for this. I would generally avoid this though.
Anyone else stumbling into this thread from a google search.... you can do this with autohotkey. If you browse to yourbankhere.com and chrome fills in the user/pass, you can have autohotkey perform a mousemove then a mouseclick to click the login button.
SharePoint 2013 doesn't use Session cookies by default, but rather persistent cookies. Based on several articles, including this one, you can force SharePoint to use session cookies by the following PowerShell command. I ran this command in my SharePoint environment.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
My goal is to make a user re-authenticate when they close and re-open their browser. For both Forms Authenticated users and Windows Authenticated users, this works great in Firefox and IE. However, in Google Chrome, when I close/re-open the browser and navigate to my SharePoint site, it remembers the user that I was authenticated as before I closed my browser; which is baffling, considering this is supposed to be a Session cookie. This happens for both Forms Authenticated users, and Windows authenticated users.
FedAuth Session cookie, given by SharePoint, as seen in Chrome
Any ideas why Google Chrome (but not IE or FF) is "remembering" my credentials upon browser close/open?
SharePoint Version: 2013, on-premise.
Chrome Version: 42.0.2311.152
Other Notes:
WindowsTokenLifetime is set to it's default value, 10hrs
FormsTokenLifetime is set to 2 minutes
LogonTokenCacheExpirationWindow is set to 1 minute
Update:
I tried closing all identifiable Chrome.exe processes via Taskmgr, but the next time I opened my browser, it still remembered me. However, I restarted my computer, opened the browser, and it didn't remember me that time. I don't think this is a SharePoint issue, but rather a Chrome issue. My guess is that some Chrome process is staying alive somewhere, even though it appears to be closed, thus allowing the "Session" to remain open. Still investigating...
Apparently, when you let Chrome run in the background, the Session cookies aren't expired (even though you've closed the browser). Disabling background mode causes Chrome to forget your Session cookie, as it should.
Note: I'm curious if this a bug in Chrome. This behavior seems to go against what a Session cookie is.
a cookie that is erased when the user closes the Web browser. The session cookie is stored in temporary memory and is not retained after the browser is closed
Update:
According to Google, this is expected behavior (though I'd consider that notion debatable). Also, another SO user also came across the same issue.
I'm trying to create a phonegap app which simply holds either img tags or iframes, all of which come from a number of different servers on our network.
The current challenge I'm facing is, when you navigate to, for example, http://my-intranet-domain/image.png in the browser, you are given a login dialog to enter your active directory credentials; when you put this as <img src="http://my-intranet-domain/image.png" /> in the phonegap app (or even Chrome and Safari on a macbook), you simply get 401 Errors (no challenge for credentials).
How can I:
Challenge for usernames and passwords in this situation
and, possibly:
After you get the username and password, remember this so you don't have to ask again (there are a number of different servers these images/iframes may come from, but they're all on our domain -- if you have to authenticate, you should only authenticate once).
The webviews don't present a dialog by default. You may want to look into cordova-plugin-auth-dialog which enables this behavior for Cordova apps. It can persist credentials for the session and on iOS it can persist them forever.
I want our app to show the online help page (so it's always up to date) or even a local page. However, it's likely to be blocked by the Firewall (Zone Alarm).
BTW, I tested this with Zone Alarm. It blocked access to a local .html file as well as to an .asp file on the internet. (I.e., tried to display a page in Internet Explorer and got the Zone Alarm dialog asking if I wanted to give permission to display
Is there a way around this?
Perhaps displaying the web page in the Web Browser Control?
It's actually very unlikely that web traffic is blocked at the firewall (unless you mean the file type is blocked?). What you may need to do in such a setting, however, is use the same proxy that IE uses, because direct traffic may be blocked.
The simplest way to do that is to use a high level windows API or IE itself, and HTTP download the latest helpfile if there is a new one - these mechanisms should know about any proxy.
Of course, your users may not be using IE, even if most are. So you might need to allow the user to specify the proxy, or be able to auto configure the proxy in the same way that the browser does it.
edit: I see you mean zonealarm is part of the problem. yes, that is tricky as you will have to either get your application 'blessed' centrally by whoever manages zonealarm in the customer organisation, or (if there is no central management) then the user will have to allow the app to communicate. Perhaps you should bite the bullet and have the online help simply be a website, and spawn the preferred browser via 'executing' the URL as suggested in another answer.
If the web browser isn't blocked the firewall then they probably open port 8080 for any app and thus your app shouldn't be blocked.
If the firewall only allowed port 8080 to IE; you would have to punch a hole in the firewall to use a new browser like firefox or chrome.
To open a web page using the user's preferred browser (with appropriate proxy and authentication settings), use something like ShellExecute with the URL of the document to load. Something like this would do it (where page is the URL to load):
HINSTANCE r = ShellExecute(NULL, "open", page, NULL, NULL, SW_SHOWNORMAL);