Flow Control, Confirm Password Options

[Forca]

Hi

I have two questions:

1. Why do online forms always as for confirm password when registering?

2. Suppose I have a webpage with a form. When the user (client) requests my webpage from the client browser, my webserver sends the html code which the client browser reads and displays the webpage with the form. The user populates the form at the client side and then presses the Submit button. From here on things get a bit tricky for me. My understanding is that the info submitted in the form is captured in a key-value array and made available to the PHP script (as per the action parameter in the form element) to which the info is POSTed. The PHP script in my cases then takes the values from the array and uses it to populate a MySQL database.

What happens once this is done? For example at the end of my PHP script I have an echo command to let the client know that the registration has been successful. And that is the end of my php script. What happens then? Do I have to tell the php script to return to the html file that initially called it?

Where am I going with this? I would like the client to see on his screen,"Registration successful!". Below this I want a link "Return to home".

How do I get the php script to return control to the calling html page?

Thanks.

[pandy]

1. They don't.

2. Yes, if that's what you want the script to do, you need to add that functionality to the script.


http://google.com/search?q=form%20return%2...al%20page%20php

[Forca]

Well, sometimes when registering, you are asked to choose a password, and then to repeat by entering the same password to confirm. I was wondering why?

Thanks.

[pandy]

When registering, yes. How do you mean it would work to login if you don't have a password? Or do you mean a password should be assigned to you? That's a possible way to do it.

[Forca]

Pandy, I'm talking here specifically about registering where the user has to choose a password. I am interested to know why the user has to confirm the password. Thanks.

[Darin McGrew]

I am interested to know why the user has to confirm the password.

It's the same reason the user is asked to confirm any other critical bit of information (e.g., email address, bank numbers). The designer of the form wants to make sure you typed the information correctly, so you have to type it twice. If you type it the same way both times, then there's a higher chance that you typed it correctly (or copy-pasted it from somewhere reliable).

[pandy]

Ah, sorry. I read sloppily and didn't realize it was the confirmation you wondered about.

[Christian J]

If you type it the same way both times, then there's a higher chance that you typed it correctly (or copy-pasted it from somewhere reliable).

I've read that some sites use javascript to try to prevent the user from copy-pasting, not sure I understand the rationale behind that.

[Christian J]

What happens once this is done?

It depends on the form script.

If the script is located at the same URL (and usually in the same file) as the HTML form, the script may simply print a different version of the HTML page that says "Registration successful!" instead of displaying the form fields again.

If the script is located at a different URL than the HTML form, you can let the script send a HTTP redirect header back to the form page, or the script can simply create a simple HTML page with the message and link.

It gets trickier if the registration was not successful, then you need to display error messages. Some sites just ask the user to use the Back button to go back to the form and make corrections, without any further guidance. A perhaps better (but more complex) solution might be to show the invalid form right away, with errors highlighted. Note that client-side form validation is not always supported by the users' browsers, so it can't be relied upon for this (and definately not for form data sanitation for security reasons).

[pandy]

I've read that some sites use javascript to try to prevent the user from copy-pasting, not sure I understand the rationale behind that.

My bank used to do that on the page where you pay your bills. Totally pointless, borderline moronic actually. If you have the OCR number on the computer, of course it's better to copy-paste than to try to get it right by typing it.

But otherwise, with registration forms, with double fields for email address and such, I do see the point. If you make a typo and just copy it over from one field to another, well, then they don't have your email address and no way of contacting you about it either in most cases.

[Forca]

With regards to my point 1 - confirming password: I've google'd it and oh dear, there are lots of different views as to whether confirming password is necessary at all. Some believe email verification does a better job, others not.

Darin - I suppose there is merit in ensuring the user types correctly, so that there is a better chance that the intended password gets stored in the database. If there was no confirm password, then the password entered may not be the password intended. Going through password retrieval is something no user wants to waste time on.

Christian - it makes sense to not allow copy paste for if the 1st password entered was already incorrect then that same incorrect password will be copied to the confirm password field with the result that the confirm password has been defeated. The user now goes away believing that he has entered a given password. Meanwhile an incorrect password has been stored in the db.

[pandy]

With regards to my point 1 - confirming password: I've google'd it and oh dear, there are lots of different views as to whether confirming password is necessary at all. Some believe email verification does a better job, others not.

I don't think the two methods have the same purpose. Type the email two times to lower the risk of typos. Email verification to be sure it actually is the owner of the address that wants to sign up. Some people find it amusing to sign others up for all sorts of thing. If someone was mad at you they could sign you up for hundreds of newsletters from different web shops. Or maybe put you on dating sites with a picture and a vivid description of your preferences...

[Christian J]

I suppose there is merit in ensuring the user types correctly, so that there is a better chance that the intended password gets stored in the database.

This may only be practical with simple passwords (that you shouldn't use anyway), while it can be very hard to type a complicated password correctly in a masked PW field even once, let alone twice. Because of this the user may want to write the password in a text document before copying it into the password field.

it makes sense to not allow copy paste for if the 1st password entered was already incorrect then that same incorrect password will be copied to the confirm password field with the result that the confirm password has been defeated. The user now goes away believing that he has entered a given password. Meanwhile an incorrect password has been stored in the db.

That depends on where the copied PW is taken from. If it's copied from the first PW field I agree a mistake can be made. A better approach might be that the user first types the PW as plain text (e.g. in a text editor, where it can be checked manually), then copies it from there. An even better approach might be to allow the user to (optionally) view the PW field as plain text while typing in the password (this can be done by toggling the INPUT field's TYPE attribute between "text" and "password" with javascript).

BTW, how do various PW managers deal with PW confirmation fields? The ones I've used let you type the PW into the web page's PW field, and only ask wether to store it once you submit the form --do they all work like that? If a PW manager lets you create the PW in the program itself, and then pastes it into a PW confirmation field, you may get into trouble.