Password field question

[astahl]

Hi,

I have a ACH payment WebForm which has a ACH local user name and password fields. So when they make an order  they can press the ACH payment button
and put in there local ACH username and password which is validated.

What is weird is if I set the ach password field as a password it puts the users login information in the fields instead of being blank. I have set the priming on change to null
but to no avail. Can you not have 2 password fields on different forms in a website?

Ashley

[Bruce]

Do the fields have the same _name_?
ie are you using the same field for the login and this form?

I think the browser is auto-populating the fields for you.

Or possibly you have SessionValues set on the server side? But then it would happen regardless of whether the field was set as passworded or not.

cheers
Bruce

[astahl]

Hi Bruce,

The local field names are different, they both start with loc:ACH_.

Yes it is the browser filling them in automatically. The reason I know this is because it is filling them out with the sites login info.

So you are saying the browser thinks that because a field is set as a password, it has to fill them in with the login info?

Can this be stopped?


Ashley

 

[Matthew51]

I have the same problem and I can confirm it's the browser applying the saved password to everything it thinks is a username and password on the same domain.  We have been telling our users not to let the browser save the password, but they don't always listen.

I have also found that if their is anything in those fields chrome won't try and auto fill them.  Though this isn't always practical.

[astahl]

We have a site that was created using CodeCharge Studio and it had a page similar to mine and it never allowed it to be prefilled by a browser. So I am wondering what/how it could stop the browser from doing that.

I found this from a google search;

Old Solution

Just use <form autocomplete="off"> and it prevents the password prefilling as well as any kind of heuristic filling of fields based on assumptions a browser may make (which are often wrong). As opposed to using <input autocomplete="off"> which seems to be pretty much ignored by the password autofill (in Chrome that is, Firefox does obey it).

Updated Solution

Chrome now ignores <form autocomplete="off">. Therefore my original workaround (which I had deleted) is now all the rage.

Simply create a couple of fields and make them hidden with "display:none". Example:

<!-- fake fields are a workaround for chrome autofill getting the wrong fields -->
<input style="display:none" type="text" name="fakeusernameremembered"/>
<input style="display:none" type="password" name="fakepasswordremembered"/>
Then put your real fields underneath.

I tried this using "Hidden" but could not set the type of field to password. I left them as string fields and set the fake password field as a password and the browser filled the first to fields as I expected. Next challange is not to get them not to display.

I also found that JQuery has a solution "jquery.disable-autocomplete".


Ashley

[Bruce]

thanks for the update Ashley.

[astahl]

Hi Bruce,

How would one set a string field to "display:none"? When I added this in firebug to one of the fake fields it hide all of the fields on the form.

Ashley

[Vinnie]

Hi Ashley.

Maybe set the String Picture to @S0 (S Zero)

[astahl]

Hi Vinnie,

That just makes it blink all the time.

I think I found the solution not sure how to implement, Bruce maybe you can enlighten me.

If I change the

element.style {
   display: none ;
}

In FireBug it no longer displays that field which is perfect.

So do I add something in my custom.css file like

.my-hide-field {
   display: none ;
}

Ashley


And then put it in the CSS for that field?

[Bruce]

Hi Ashley,

there's a built-in class you can use
nt-hidden

cheers
Bruce

[astahl]

Hi Bruce,

I tried that before and it of course hides them but it shows the username and password fields filled out.

From what I am reading the element.style overrides all CSS. I did see some code using java script that they claim
overrides the element.style.

Ashley

[Matthew51]

I have a solution that works, and doesn't include hidden fields.  According to Mozilla we need to set  autocomplete="new-password"
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

First turn ON Allow Browser Auto-Complete in the template for the password field.  This will prevent net talk form adding autocomplete="off" to the field.  Then in the Value Routine embed for your password put

Code: [Select]

loc:extra = 'autocomplete="new-password"'Done!

I've tested it in both Chrome and Internet Explorer (win 7) so that should cover at least 90% of browsers.

[astahl]

Hi Matthew,

Your the best!!!!!!!! Great investigative work!

I just about given up on it to move onto other problems with our AWS ELB(load balancer) almost have that resolved.

Is loc:extra your password fieldname?

Ashley

[Matthew51]

Nope it's a net talk variable that adds extra stuff inside the tag.  So just copy-paste.  I did my test using the basic login example.

And I just noticed their's several "Value Routine" embeds for each field.  The one you want is "4 Value Routine".

Also when I when to put this into my main app the Allow Browser Auto-Complete was disabled and I have no idea why.  It still works as the code will put autocomplete="new-password" before autocomplete="off" so the browser will take the first one.  Though it's bad code to have them both their.

Perhaps the template could be changed to a string option rather then a check box as their are a lot of option for autocomplete.

[astahl]

Hi Matthew,

I did as you said and removed the 2 extra fields I had on the form.
I had the actual password field unchecked as a "Password", ticked it on.
Checked "Allow Browser Auto-Complete" and in the Value Routine 4
I added in loc:extra = 'autocomplete="new-password"'

Now it adds the users login credentials and the password field shows the characters.

WEIRD!!! Guess I may have to start over with this proc.

Ashley