When I submit a form with a password field in, for example, Firefox, the browser asks me if I'd like it to remember the username and password for me. For example, logging into gmail in Firefox, I get this message in a popup:
Would you like to remember the password for "markamery#gmail.com" on google.com?
with 'Remember password', 'Not now' and 'Never for this site' options.
I'm developing a plugin that will be used to provide a service on multiple websites. Users will have an account on our mysite.com, and our clients, like someclient.com, include a Javascript script from mysite.com on their webpages which adds our content and functionality to their page, including a login form that users can use to sign in to our site. (The actual mechanics of the login process are all handled with iframes, AJAX and HTML5 postMessages, not that it matters).
When users log into our plugin on someclient.com, I want their browser to prompt them to remember the password on mysite.com, and when they see our login form on someotherclient.com, I want it to be autocompleted with the same username and password that they entered into it on someclient.com. However, currently, they get a prompt asking
Would you like to remember the password for "yourname" on someclient.com?
instead, which isn't what I want.
Is what I want possible, and if so, how?
Putting the form inside an iframe will cause Firefox at least to associate any stored passwords with the domain of the iframe instead of that of the main page. You can communicate with the iframe using postMessages.
Just have the iframe catch the form submit event, serialise the content of the form, and send it to the main window via postMessage; then the main window can grab the content of the form from the message and handle it using Javascript.
Of course, even in simple cases this is a fairly ugly hack, and if there are complicated interactions between content in the iframe and content or code in the main page, then trying to handle them all properly via postMessage may result in a quick descent into pain and spaghetti. If the value of having cross-domain password autocompletion is low and the main issue is that having a remember password message featuring the wrong domain name is bad, then consider simply disabling the feature altogether instead of mutilating your codebase with hacks to fix it. You can disable it by setting the 'autocomplete' attribute of the form to 'off', as described here: Disable browser 'Save Password' functionality
Related
My web app shows a list with items with certain properties. Each list item is a row, which amongst others an email address. When the row is clicked, it expands and shows more information.
All works fine on the desktop, but on mobile, Chrome recognizes the email addresses and on click it opens the email app to write an email to this address. I didn't set this myself, so this seems to be default behavior.
Is there a way to prevent this from happening?
The code to show the email address:
<p class="text-ellipsis"><em>someone#example.com</em></p>
I like to inject "zero-width no-break space" characters to fool helpy mobile browsers
<p class="text-ellipsis"><em>someone#example.com</em></p>
I ended up putting the email address in an tag, then styling this as normal text and disabling the default action through javascript. This way the browser thinks an action is already connected so doesn't do anything when clicked.
Since I was loading the data from a database query into a Django template, any option to add characters in the address itself would've not been possible.
Using chrome://settings/handlers then set "Don't allow sites to handle protocols" worked for me.
I have working the auto population of this form: http://getpocket.com/save
I'm using it rather than the API so that it works when users are logged into Pocket on the same browser as my website.
However, it's not a good user experience to then have to click 'save', so how can I "automate" that?
I won't show my code, because it essentially is just to generate a link of the form:
http://getpocket.com/save/?title=thetitle&url=encodedurl
It populates the form fine, but how can I submit? I tried apending &save and &submitand then each of those =True, in vain. Is the issue that the save button doesn't have a name= field, which is what's used to hook into the title and URL fields?
EDIT: Just to be clear, I didn't have any malicious intentions, only to save articles to read later on click of a button.
If I find the time I'll have a look at the API.
Luckily this is impossible (on Pocket and most sites) due to cross site forgery request protection to prevent exactly what you are trying to do.
A token is set in the form and together with session information for the user on pocket (or any other site that uses csfr token protection) it will need to form some sort of secret hash. When the 'save' form is submitted the combination of these strings will be checked and normally new strings will be set. Because there is (practically) no chance that you will be able to predict the token form the form itself and have no real way of manipulating the session hash, you are out of luck. And we are all very happy for that :).
Otherwise you could make links on other sites that would delete your whole database when you happen to click on them, etc.
In short: You can't.
On any form without csrf protection you'd have to target not the url of the page with the form, but the 'action' of the form. You can see this action by inspecting the form with your browser's DOM inspector. But, as I said, csrf protection will prevent this from working most of the time.
http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?
I am working on a login dialog to my site. To spare users the frustration of having to remember their login details, I want to cooperate with the built-in browser password managers. I have worked out that to get Firefox to play ball, I must use a plain-vanilla HTML Form. Fine, so be it. However, I will not transfer unencrypted passwords. So my form content looks like so:
input#1 type="text" name="login"
input#2 type="password"
input#3 type="hidden" name="passwd"
I then intercept the submit and encrypt the content of #2 into #3, and off goes the form. Works a treat in IE and Firefox, not so in Opera and Chrome. Just rifled around SO and find that the problem is input#2, which does not have a "name" attribute. A quick test reveals that when I add name="ignore" it does work indeed in Chrome and Opera. Only trouble is that the password is now sent across the network plain text, with the label "ignore". Thanks a bunch. The whole point of omitting the "name" was to omit that field from the form.
If there a way that I can suppress input#2 from being sent while still giving it a "name"? Or is there another trick I could use?
Thanks.
The answer in the narrowest sense of the original question is: yes, it is possible via Ajax. Create a vanilla FORM with two named INPUTs and submit BUTTON. (Don't forget to feign some action in the FORM attributes.) Now it looks like a plain-text HTML affair. Next in JS, intercept the onsubmit from the FORM and launch an Ajax request to your PHP script, POSTing the plain login and hashed password. Return FALSE from onsubmit to suppress the FORM's action. You're done. No more plain-text passwords across the wire...
My company website, which I develop, requires a login using a form.
Firefox correctly asks for and remembers login details, but test instances of IE6, IE7 do not remember either the username or password, and IE8 will give a dropdown of usernames previously used, but will not remember the password.
What is it about the design of my password form that allows or prevents IE from prompting?
Can I alter the design of my page so IE will remember username/password form data (assuming the user has their preferences set correctly)?
Is there some magic HTML tag, name, or style I should be using?
You might try looking into DOM storage to store username/password persistently on the client side. It'll require JavaScript though and won't work in older versions of IE.
Try adding the site(s) you're trying to access to the "Local Intranet" zone, rather than the "Internet" zone. (assuming this won't cause you security worries)
Tools/Options/Security/Intranet/Sites/Advanced --> add your site(s) here. In my experience, by putting them in the more highly trusted "Intranet" zone my passwords are remembered.
I assume the input box for the password is set as an input type of password?
One thought I had was to explore the naming convention of your form and input fields. Perhaps IE is looking for certain combinations to know that this is a login form that it can offer to save the login credentials for. Also, I have noticed that some web technologies/languages read different elements to get the field names. You might need to set your input fieldnames using both "id" and "name" to get everything to work.
Does your IE remember passwords for other sites than your company website?
Just want to make sure you have not disabled password storage in your IE.