Jump to content
Larry Ullman's Book Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Larry

  1. It wouldn't make any sense to prevent a user from using the same password as another user. I've never seen that done. As for forcing people to reset their password, that makes for good security but it's still not that common and definitely not common--in my experience--in places it matters most, such as financial institutions. I also personally find prevention of re-using a password to be annoying, although not a terrible inconvenience when using a password manager. My current approach is pretty strongly a matter of: tell users how to be smart about their passwords but don't put many restrictions on what passwords they actually use.
  2. I assume you're putting blank values into the database then. Right now you bind 7 variables to parameters but only assign values to 5 variables.
  3. Thanks for sharing what you found! Personally, though, I'd still use the GET method here. POST doesn't really make sense in this case.
  4. Most likely this is because you don't have an input named 'pass' in your form. On another note, though, it's not a great idea to store the user's password in an unencrypted manner.
  5. Thanks for the interest in the book! I do appreciate it. I don't actually have a list of changes, however. I'd recommend checking out what's changed in PHP since the book was written. The major changes there are probably most important for your case. Best wishes with your studies!
  6. Okay, two ways of going about this. The first is to make a SELECT menu whose option value is the category ID and then you add the JavaScript that redirects the browser when the selection changes. Alternatively you could create an unordered list of links that's collapsed into one menu using JavaScript and CSS. I think the later is likely more common.
  7. As far as I know, the only way to make a SELECT work as a list of links is to use JavaScript to redirect the browser upon changing or selecting an item in the list. I don't think that's something you want to do. As for your MATCH...AGAINST, you probably don't have a fulltext index set on sizes.size, which could cause that error.
  8. So I assume that limiting by number of views means a certain number of views within a specific time from (e.g., 10 per month). I'd start with the standard subscription model, where you store the date and then refresh the date with every successful payment (i.e., add a month). This separates active subscriptions from inactive ones. Then create a way of recording views, maybe in another table. When the user views a page, check how many views they have in the current period (i.e., since their last payment date). If they have none left, print that message. If they have any left, show the content but update the record of views.
  9. It definitely sounds like the virtual subscription model is the correct choice for you.
  10. From the error message it looks like you're trying to treat a variable as an array but it has a null value (i.e., it's not an array).
  11. Glad to hear it! For what it's worth, haters have been predicting the death of PHP for forever. But it's still in use by 80% of sites, including Facebook, Wikipedia, and everything WordPress. It's a zillion years from obsolete! And, honestly, anyone claiming you should move from PHP to Python has NO IDEA what they're talking about. Python is a fine language, but the notion of going from PHP to Python for web development is bonkers.
  12. Thanks for the question! I'm not terribly worried about this. Microsoft said they're not going to provide builds of PHP for Windows anymore. Certainly someone else will pick up the torch. Also, to me, this is more of an issue for people learning or developing on Windows. I don't have hard numbers but I assume the vast majority of servers using PHP are running Linux.
  13. Thanks so much for sharing all that, Max! Kudos for your success in stopping more of the dreaded spam.
  14. Yes, both versions are comparable with respect to validating the gender. To use the NULL coalescing operator in Script 2.4, you'd probably just write it like your version of Script 2.3 (note that you don't need the $gender = NULL in there though).
  15. I wouldn't say that line is necessary. The $gender variable is already assigned a value before being used so assigning it a "false" value has no impact.
  16. For starters I definitely wouldn't put this into the users table. That table represents an entity: the user. What you're describing is representing activity, so I'd create a logins table for that. As for the goal itself, as I'm sure Netflix can attest, this is tricky and may not be worth the effort. You can't assume people will log out, as you noted. But that also includes situations like I start using the site on one device but then go to switch devices. I definitely access some sites on multiple devices in a single day. In any case, the best thing I can think of would be to rely upon sessions here. Store the session ID in the database, along with the user ID. Sessions will automatically expire after inactivity, based upon your site/server settings. When someone logs in, you could check if there's an active session already. But I wouldn't bother, personally. You'll have to create a lot of work to hopefully catch a few cheaters while occasionally annoying legitimate users. I'd rather put my effort into making a product so great people would gladly pay for it.
  17. That's an excellent question! Depending upon what it means to be an "admin" user, I'd be inclined to not allow admin users to reset their password at all. If a password is forgotten, the admin should personally contact the site--who presumably knows the admin--who would manually help with the reset. Such an arrangement, while inconvenient, would prevent a hack attempt.
  18. It looks like this is most commonly caused by InnoDB settings: https://stackoverflow.com/questions/22637733/mysql-error-code-1118-row-size-too-large-8126-changing-some-columns-to-te/33655143 If you'd like to keep the current approach and aren't going to add like double the current number of columns, you can try that. If this is going to continue to balloon in size, you'll need to dramatically rethink how translated text is stored. An option would be to switch the rows and columns. You won't have the row size issue anymore but you'll need to select the one column for every row and then use that query to populate a PHP array, which is laborious. Alternatively you could store all the translations in one string, like in JSON format. Retrieval and usage shouldn't be too bad but updating the values will be effortful. There's a number of ways you could approach this but those are the first two that come to mind. Everything has its tradeoffs!
  19. So I believe the page gives that result if that "SELECT a.user_id, u.email, LEFT(u.first_name,1) AS icon, ..." query doesn't return exactly one row. There wasn't anything obviously amiss there upon first inspection. I would run the query manually using the mysql client to see why it's not returning a row. (You'll need to insert the token value into the query, of course.) Try removing various conditionals to see which is the problem.
  20. So you need to clarify which date_expires you're referring to by prefacing "date_expires" with the table name or alias. As you're probably referring to the access_tokens table, which has been aliased to "a", you'd change the conditional to "AND a.date_expires > NOW()". What you tried was close but a query only has one "FROM" clause and you added a second one as part of the "WHERE" conditionals.
  21. The code you have looks okay to me. If it's not working, I'd start by looking at the HTML source of the output to see if there's something useful there. Also, should you be using POST or GET?
  22. Ah, good question! There are two options: A. Use the current code but before the current session is destroyed, copy the lang ID to a new variable and then after the current session and cookie are destroyed, start a new session and store the lang ID in that using the variable. or B. Don't clear and destroy the session in this script, only remove those session elements that represent "being logged in".
  • Create New...