Logging In

[bnorg]

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.

[Larry]

(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?

 

I don't know that one solution is more logical than another. It's just a matter of how you want to do it. Arguably, I would imagine that usernames would be publicly visible, whereas email addresses would not be, thereby making it more secure to use the email address to log in. Six of one, half dozen of the other, really.

 

(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?

 

Not exactly. Step 12 handles both being taken, in two different records (i.e., this user has already registered this email address and another user has already registered the username). Step 13 handles one or both begin taken, but in a single record. As for the question about the error messages as literals, I'm not following what you're asking there.

 

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

 

You don't ask any question here, so I don't have an answer. You seem to be suggesting something about queries being quick for validation using stored procedures in ASP.NET. That may or may not be true, but regardless, the point I'm making is that any file input/output, including a database query, will be the most taxing thing a PHP script does, so you should limit those occurrences as much as possible. If you do have a question here, let me know and I'll try to address it.

[bnorg]

(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?

[HartleySan]

Here's my best attempt at answering your questions:

 

(2A) I don't have the book in front of me, and honestly, I'm a bit confused about this, so I can't comment on this at the moment.

 

(2B) You can very easily created constants for messages, and use those constants for messages. The easiest way would be to place the constants in the config file that already contains other constants and is loaded into most scripts. That way, you don't have to include any other files.

 

(3A) Database calls are expensive any way you slice it. And ASP does not magically work faster than other scripting languages. If anything, I'm willing to bet that ASP (even the new version) is slower than PHP. What I can say though is that using stored procedures (or prepared statements) is faster than running individual queries every time. They're faster because the queries are already prepared before you make a call to one, thus reducing the time need for each one.

 

(3B) I think it's best to take the examples in Larry's books as just that, examples. I think he provides short, simple messages just to get the point across. You're welcome to expand on them as much as you want.

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

[Larry]

(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?

 

Superglobal variables are not prefixed by $_SERVER. $_SERVER is an example of a superglobal, as is $_SESSION, among others. I have no idea what you mean by "HTML's session variables".

 

(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?

 

No, it's because the second example site does not require (or allow) the user to log in. if you want that feature, you'd apply the information from the first site to the second, as I explain in the book.

 

Also, you seem to come from an ASP background. Just so you know, this book does not teach fundamental PHP and MySQL. It assumes that the reader already knows the key concepts.

[HartleySan]

bnorg, related to Larry's last comment, his PHP 6 & MySQL 5 book is really good, and teaches the fundamentals of both. I highly recommend it.