Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5308
  • Joined

  • Last visited

  • Days Won

    146

Posts posted by Larry


  1. I'm not sure what you mean by "combine the two queries together" as one is an INSERT and another is a SELECT. They cannot be combined into one. But from the looks of it what I think you should be doing is executing the INSERT query, then checking for affected rows, then executing the SELECT query.

    Also, separately, it's pretty weird to print out JavaScript like you're doing as opposed to just redirecting the browser directly within PHP.


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


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


  4. 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. :)


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

    • Like 1

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


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

×
×
  • Create New...