Jump to content
Larry Ullman's Book Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Larry last won the day on December 9

Larry had the most liked content!

Community Reputation

412 Excellent

About Larry

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sorry for the confusion here. It's a subtle difference. Here's what the MySQL manual says: and I guess I'd phrase it as ~ being more impactful than <.
  2. The second line is not actually manually setting the cookie, it's manually assigning a value to an element in the $_COOKIE array so that you can refer to it later in the script. I wouldn't say this approach is less secure necessarily, but it's a bit of an artificial workaround (by that I mean it allows you to refer to a $_COOKIE variable before it should have a value).
  3. Yeah, sorry about that. Those should be using different cases. Thanks for reporting! Also, could you clarify what you mean by "digital online copy" so I can make sure it gets fixed?
  4. You'd need to start off with what kind of information would be needed. Look at what questions may be asked of the system and what information would be expected in the response.
  5. Just to clarify, this would be an Apache and XAMPP issue, not a PHP one: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrandomseed I assume XAMPP has them commented out by default b/c people may not be using these in particular, so they just have representative values. Personally I never spend any time worrying about the local SSL stuff as it's just a dev environment. As for the bytes argument, the more bytes the more secure but also the more processing required. You'd want this to be an appropriate value for all the parameters of your system.
  6. Unfortunately I'm not familiar with the changes in any detail and don't see anything discussing what to do instead. Sorry I couldn't help on this one!
  7. Thanks for your post and for your interest in the book. PHP7 and HTML5 are the main changes in the 5th edition. Considering everything, you should stick to the 4th edition that you have!
  8. At least a part of the problem is you're referring to variables in the wrong order. For example, one of the first lines in your function is: var regularPay = parseFloat(regularHours*hourlyRate).toFixed(2); But neither regularHours nor hourlyRate has a value at this point. I would recommend two approaches here instead: 1. Start with the smallest concept first. 2. Create comments describing the logic and then implement the logic in code. For example... # See if hours worked is greater than 40 which becomes # Get a reference to the number of hours worked # See if hours worked is greater than 40 which becomes var hoursWorked = document.getElementById('hoursWorked').value; hoursWorked = hoursWorked.toFixed(2); if (hoursWorked > 40) { alert ('Greater than 40!'); } and so on. (You can also use console.log() to output values and results to the console.) By doing this more incrementally you can build up a working model while better understanding what's going on and the use of comments should help you avoid getting too far ahead of yourself.
  9. I think you're missing an equals sign. This code-- if (mysqli_num_rows($r) = $username) { --is trying to assign the value of $username to mysqli_num_rows($r), which of course isn't possible. You want == $username instead. But that still won't work because mysqli_num_rows() is going to return an array and what you need to do is compare an element in that array to $username.
  10. You'll just need to use the mail() function. You can learn all the details and see examples in the PHP manual: http://php.net/manual/en/function.mail.php
  11. Ah, excellent find and fix! Kudos for figuring that out and thanks for sharing the solution!
  12. Yes, you're on the right path. And the concepts are a bit confusing. Remember that cookies are sent back and forth between the server and the browser. The $_COOKIES array is populated by the browser sending cookies back to the server. On the login page, the PHP script sets the cookie which means the cookie doesn't exist when the page is first loaded (i.e., it's not sent from the browser to the server upon login submission). So the logic has to factor in that the login page DOESN'T have the cookie, despite actually setting the cookie. Conversely, the cookie exists on the logout page when the page is first loaded but is then deleted (i.e., the cookie is sent from the browser to the server when accessing the logout script). This means the logic has to factor in that the cookie DOES exist upon first running the page. It probably also helps to remember that the includes become part of the page that included them. So when login.php is run without receiving a cookie from the browser, the included file also don't receive that cookie. (In other words, the execution of the included file is not a separate request from the browser.)
  13. It looks like PayPal is now using the lowercase "verified" for the payer_status. You could switch to that or use stricmp() instead.