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.

[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.

[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.