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.
Related
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.
If I inspect an <input type="password"/> from my Tampermonkey script and observe changes using a change handler for a password field that is filled by the Password Manager feature of Chrome, the value remains empty until I physically perform a real click in the page. I have tried in my script clicking in the page, but Chrome knows it’s not a real click. When I physically click in the page, the change event suddenly fires, the password field gets a value, and then my script reacts properly (due to having the change event). But I wrote this script to avoid having to interact with the page in the first place, so this defeats the point of my script.
Is there a way to get TamperMonkey to mark the page as having had the user interact with it (e.g., some hypothetical GM_setUserTouched() or GM_autoFillPasswords() API) so that the Password Manager feature actually fills the <input type="password"/> in without requiring me to click in the page?
Background
In Chrome, this behavior is documented in #352527 comment 15 where it is unexpected behavior to the reporter and #398805 where there is a case that Chrome fails to implement the behavior I don’t want. It is considered a feature that when autofill and Chrome’s built-in Password Manager fill out a form, password characters are displayed to the user in the password field, but the DOM HTMLInputElement.value is set to "". When the user interacts with the page, such as by clicking in it or pressing a key, Chrome modifies HTMLInputElement.value to contain the password and a change event is fired at the element. The cited reason for doing this is “security reasons” (e.g., if a website script was reading from the password element, it only would have a chance to do so if the user was looking at the page… so popunders or non-visible frames wouldn’t be able to do it or something? I’m not sure what this protects you from: once the user interacts with the page, all of the scripts would have access to the password anyway. And if bad scripts are being served from the same origin as the <input type="password"/>, the website itself has a security flaw, not Chrome…).
Greasemonkey historically has helper APIs and a #grant system to enable the userscript to work around issues like this. Edit: when creating the repro (below), I discovered that Firefox makes the autofill password available to the DOM without waiting for the user to interact with the window. Thus, Greasemonkey doesn’t need a GM_forceAutofill() API because Firefox doesn’t exhibit this Chrome quirk. As a result, Tampermonkey doesn’t have such an API.
Repro
Because people do not believe me when I describe the behavior exhibited by Chrome, I have prepared a repro. It takes some work to get Chrome into a state where it doesn’t think the user has interacted with the page yet, but you should be able to see what I see using these steps:
Open Chrome. I am using Chrome 61.0.3163.91 64-bit on Windows 10.
Navigate to https://fiddle.jshell.net/xqfynp3e/22/show/light/
Enter some bogus username and password and hit enter or click the button. Chrome should prompt you to save the password.
Save the password.
Open Developer tools.
Enter this into Console (to navigate to the page without accidentally interacting with it): window.location.href = 'https://fiddle.jshell.net/xqfynp3e/22/show/light/?1'
Run document.querySelector('input[type=password]').value in Console.
Observe that the form’s password appears to be filled in visually and yet reading the DOM element in Console yields "".
Click in the document.
Run document.querySelector('input[type=password]').value in Console again.
Observe that the form’s password hasn’t changed appearance and yet reading the DOM element in Console yields the bogus password you saved.
My question, restated: how can I get Tampermonkey to perform the “Click in the document” step? How do I tell Chrome’s password auto-filler that I interacted with the page without actually physically interacting with the page?
EDIT: I have found an alternative way to securely store passwords in Chrome and access them via userscripts by using the Credentials Web API’s silent mediation support: https://imgur.com/a/ts2W1
You cannot do this using Google's built-in password storage because, as you stated yourself, Chrome requires user interaction to enable such passwords -- as a security feature.
Specifically, Chrome requires an event with the isTrusted property set to true. Tampermonkey cannot work around this because even Chrome extensions are not able to set the isTrusted property.
See also, this related feature request from 2015.
One solution is to use a password manager that fills these fields without using Google's built-in storage.
There are many available, with varying degrees of cross-device, and cross-browser, support.
Or you can write your own Tampermonkey script to fill in these fields, irregardless of what Chrome has stored.
If you do write a Tampermonkey script, I recommend that you use a secure storage framework, don't hardcode login info into the script.
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.
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 have several accounts for a website and currently I want to write an extension that I can open all the accounts simultaneously in chrome, each tab for one account.
So that means I want each tab with a separate cookie system, is it doable? If so please suggest the API I should use, thanks!
Go to Chrome Preferences. There is a Users section where you can add users. Each new user will have its own cookie jar, so you can log in to a site as many different users at once. It makes new chrome windows, but it seems you cannot drag a tab onto a window of another user.
According to Chrome documentation, you can modify HTTP headers (including cookies) in the onBeforeSendHeaders event handler. So, you need to store new cookies for every account by means of the onHeadersReceived event handler, and then substitute them for every tab in outgoing requests.
There even exists an extension which seems doing almost the thing you want - Chrome Cookie Switcher.
Also I have found an answer that may be helpful for your task: Associate a custom user agent to a specific Google Chrome page/tab.
I really don't think Chrome allows extensions to do this. If I recall correctly, extensions can inspect and block requests, but they can't modify them, such as changing cookies on the fly for each tab.
I suggest you use the --user-data-dir command-line option of Chrome. It allows you to keep several separate profiles, each in its own directory, and then you only need to start chrome with the proper option:
# run this command to use the first profile
google-chrome --user-data-dir=/home/binchen/my_chrome_profiles/my_profile_1
# run this command to use the second profile
google-chrome --user-data-dir=/home/binchen/my_chrome_profiles/my_profile_2
...
Each profile will be in its own Chrome window, with its own cookie store, instead of its own tab, but it's easier than writing an extension.
Lastly, if the website you're mentioning is Google, you can keep several Google accounts open at the same time.