bnorg

I have two other related questions: (1) I have a book that briefly mentions "PHP's Superglobal Variables" that are prefixed by $_SERVER that have environment data. On page 93 you assign 'user_id' and 'username' to similar variables and on page 96 an entire array to $_SESSION itself. Are these like HTML's session variables and can you rely on the data safely being there during a session? (2) User accounts and logging in are kind of related. On page 5 you say "because you'll be storing information about customers, there are other laws involved . . . [and] the U.S. also has precise rules." I looked ahead and on page 266 it says "checkout.php behaves like register.php from Chapter 4." On page 169 there is a Customers table which must be present because the Orders table on the next page needs the customer_id. But it doesn't have a password column like the Users table has on page 52. That means that managing passswords is not possible as on pages 96-103. In fact, once the user has entered personal data, maybe he can't even go back and correct a mistake. Is that because the rules mentioned on page 5 limit what a user is permitted to do?

(2A) Is there a way to combine steps 12 and 13 for "both" for efficiency's sake or is it crucial to explain the differences of each? (2B) Is there a way to use constants to save space so the same message doesn't have to be spelled out a number of times? (3A) An assumption with ASP's callbacks is that there is plenty of power so is it true that it's not necessary to be so conservative anymore? (3B) Wouldn't the user be more appreciative if more feedback was provided than trying to say as little as possible for security's sake?

I've got three questions regarding the logging-in processing: (1) My email accounts require username and password to log in. In the book's database there is a username field but logging in requires the email address instead. Wouldn't it be more logical to require the username as long as it exists and email systems seem to use it? (2) Page 89 shows all the responses to the add-account insert. It seems that step 12 handles the "both" option of existing username and password and step 13 handles both being taken again. Is that because you have to distinguish between duplicates being in the same record or in different records? Also, the error messages are reported as literals again and again. Is that repetition required because of PHP? (3) On page 92 it says "database queries are expensive." On page 93 it says "for security purposes, the script doesn't indicate which of the two values is incorrect, or if the email address has been registered at all." I have a login page created when learning ASP scripts and about session variables which still works after adding ASP2.Net to it. Queries work fast for validation using stored procedures. Also username and password are treated individually and not bundled together losing the detail possible in a response. Since the user is only allowed a few tries for each field it doesn't seem like security would be compromised. But there may be things hackers do so you don't want to help them at all with anything.