Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5300
  • Joined

  • Last visited

  • Days Won

    145

Everything posted by Larry

  1. And if you change your script to begin <?php echo $_GET['id']; exit; It would output 1?
  2. I am not seeing any obvious problem and it sounds like you've done all the due diligence. You're saying the page, when it loads, is edit_user.php?id=1 or whatever?
  3. Make sure you create the users table before you create the orders table.
  4. You're using single quotes when those should be backticks.
  5. Thanks for the nice words! As for #1, the code would be essentially the same as that creating the page titles (e.g., in browse.php and then header. html), just populating the META instead of the TITLE.
  6. Hmmm...so that's a different error than you had before and doesn't exactly make sense given the code above. What steps had you taken when you got this error?
  7. You should print out the query (the $sql) variable to see what the full query is. Sounds like you have a syntax error.
  8. Thanks for the interest in more books! Much appreciated! The "PHP Advanced" book would be the logical one after "PHP & MySQL". Or the e-commerce book that Necuima recommended.
  9. 1) You'd store the keywords in the database along with the product info. Then you'd retrieve the product details before including the header file, making those keywords available to the header file to put in a META tag. 2) You'd need to track the user's viewing history and then you can pull from there. So when a user views a product, that stores the product ID, user identifier, and timestamp in a table. When that same user identifier appears, you can pull the info from that table by date desc order.
  10. Ah, okay, that helps! Your function doesn't have access to the database connection so it can't execute the query. I would have thought it'd kick on the !$r error, though. But try passing $dbc to the function as an additional argument and see if it behaves better.
  11. In what way is it not working? Like what isn't it doing that it should be doing or what is it doing that it shouldn't be? What is the output? What debugging steps have you taken and what were the results?
  12. Sorry for the delay; I had to reinstall XAMPP on Windows to test this out. I suspect the issue you're having is because you haven't connected Mercury to the Internet at large. In other words, Mercury needs an SMTP server to work with. This is normally your local ISP or something like smtp.google.com (if you have a Gmail account). Have you done that? This page is pretty good, by the way: https://www.open-emr.org/wiki/index.php/Mercury_Mail_Configuration_in_Windows
  13. Ah, great! Glad you're making progress and thanks for letting us know! Just to be clear, you should never mix procedural and OOP approaches like that as you won't necessarily get the errror messages, let alone the results, you're looking for. As for your question, if a query must affect one or more rows, than checking for that is perfect. But if a query won't necessarily affect multiple rows than you can confirm that it worked--or that it didn't fail--by either checking the truthiness of the query result or by checking for the presence of an error.
  14. I don't know what the "paystack api" is but if it's a good API, it should have documentation and ideally support.
  15. It looks like you're mixing both procedural and OOP styles. You need to pick and use just one. I think that's why it's not working but the error results also aren't helpful.
  16. I think you've posted this in the wrong set of forums as I have no idea what you're referring to.
  17. Are you sure this is from the PHP Visual QuickStart Guide book?
  18. Maybe I'm trying to introduce a new word into the lexicon. 😉 Thanks for catching and reporting!
  19. Could you clarify what specific script you're asking about just to make sure we're talking about the same code? Or post the actual code in question?
  20. Two things do stand out for me here. First, any time you're talking about handling money, the requirements are way more strict. You'll need to think a lot about security, but there are also legal and regulatory requirements like licensing, KYC (Know Your Customer), illegal money transmissions, etc. I can't exactly tell if these will be concerns of yours or not, but something to be aware of, at least. Second, that you're trying to use an API that's poorly documented is a cause for concern! In any case, good luck with your project and let us know if you have any specific questions!
  21. You can't rely upon a browser event for something like this. But if you use sessions or cookies, those will automatically expire. Or you can store a timestamp in the database to reflect the most recent activity and then add logic that checks that value.
  22. Understanding what makes a password strong requires thinking about how passwords can be cracked. Without getting into the system itself (e.g., breaking into the database), passwords are most often cracked by brute force: trying as many possible combinations as possible. Dictionary attacks would be an easy way to do this: start by trying common words such as "password", etc. This is why sites wanted you to not use common words as a password, which was enforced by requiring numbers and symbols. Capital letters would also be required, so that "password" wouldn't match "Password". This wasn't an unreasonable solution at the time, but two developments have since occurred. Most importantly, computers are just crazy fast now and they can brute force millions of passwords in seconds, or milliseconds. Second, most people ended up doing number substitutions that were pretty easy to guess, like "passw0rd" or "p4ssw0rd". Sidenote: These systems that require numbers and symbols also inadvertently encourage bad behavior on the part of users, such as writing down the password b/c they can't be remembered. Given all this, how do you make passwords actually more secure? The answer is by making them longer. Each character added to the length of a password makes it exponentially harder to crack. Just using the lowercase English alphabet, a single-character password can be one of only 26 possible values. A two-character password can be 676. A three-character password can be 17,576. And so on. It's exponential. So requiring longer passwords is way more important than putting restrictions on what's in the password. Two final thoughts... - In terms of customer security, the most important factors are out of your control: users shouldn't re-use passwords across sites and they should store them security (e.g., in a tool like 1Password). - Your goal shouldn't be the strongest password system or maximum customer security. Requiring passwords of at least 1,000 characters will be pretty secure--but not maximally so--but is ridiculously impractical. Your goal should be to find the right middle ground between security and user convenience for your application. This forum, for example, doesn't need very strong security, but my bank's website does.
×
×
  • Create New...