Jump to content
Forums are read-only ×
Larry Ullman's Book Forums

Larry

Administrators
 View Profile  See their activity

  • Posts

    5413

  • Joined

  • Last visited

  • Days Won

    155

 Content Type 

Posts posted by Larry

    INTEGRATING 3rd Party API To A PHP Website

    in PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (5th Edition)

    Posted

    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! 

    Regarding User Registration

    in Effortless E-Commerce with PHP and MySQL (2nd Edition)

    Posted

    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. 

    SQL Problems

    in Effortless E-Commerce with PHP and MySQL (2nd Edition)

    Posted

    I played around with this a bit. Again, I might entirely rethinking the logic, but assuming we want to keep two date columns, this create works: 

    CREATE TABLE `carts` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `user_session_id` CHAR(32) NOT NULL,
  `product_type` enum('coffee','goodies') NOT NULL,
  `product_id` MEDIUMINT(8) UNSIGNED NOT NULL,
  `quantity` TINYINT(3) UNSIGNED NOT NULL,
  `date_modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `date_created` DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `product_type` (`product_type`,`product_id`),
  KEY `user_session_id` (`user_session_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

    I put `date_created` second and changed it to a DATETIME and then it can use the CURRENT_TIMESTAMP as the default so the INSERT query doesn't need to be changed.

    Database Session Handler

    in PHP Advanced and Object-Oriented Programming: Visual QuickPro Guide (3rd Edition)

    Posted

    Okay, I just installed the DB and script and upgraded PHP to 7.3.8. Sadly, I am NOT seeing the error at all. This is using PHP's built-in server, although it'd surprise me if this was an Apache issue. I'm also testing this on a Mac.

    Unfortunately it's really hard for me to come up with a solution without being able to replicate the problem. From everything I'm reading online, having the _destroy() return a boolean solves the problem for some, but of course the code in the book already does that. 

    Regarding User Registration

    in Effortless E-Commerce with PHP and MySQL (2nd Edition)

    Posted

    Sorry for the delayed reply; had to take the time to set this all up on a server again. I ran the script with the 6 changed to 8 and it did also allow me to register. Then I realized it was probably because of the forward lookahead and the parens and where the minimum does and does not apply. Changing the minimum to apply to the whole grouping works better: 

    if (preg_match('/^((\w*(?=\w*\d)(?=\w*[a-z])(?=\w*[A-Z])\w*)){8,}$/', $_POST['pass1']) ) {

    All that being said, since I wrote this edition, both the industry and my personal feelings how validating passwords has changed. If I were to do this again today, I'd just require a minimum length (say 12 characters) and not care at all what characters are in that password. With modern computers, "thisismypassword" or "this-is-my-password" is more secure than "1Ad92q" for a number of reasons. 

    SQL Problems

    in Effortless E-Commerce with PHP and MySQL (2nd Edition)

    Posted

    I've reviewed the MariaDB documentation for timestamp: https://mariadb.com/kb/en/timestamp/

    It looks like the first timestamp column in a table has different behavior than the second. We want date_created to be automatically set on creation, but not update. We want date_modified to be automatically updated on each change. To get that behavior you'll need to change the DB and the SQL queries. Assuming we want both the date_modified and the date_created, I'd be inclined to put the date_modified column first and then populate date_created to the current timestamp upon INSERT. 

    Or just drop the date_created column entirely and update the SQL commands accordingly.

    Chapter 19 - Example E-Commerce - view_print.php - Display the Image ( not displaying!)

    in PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (4th Edition)

    Posted

    Ah, okay. First, thanks for all the details. Second, I would advise against trying random things as you debug. It's a natural thing to do but tends to lead to more confusion. Here, for example, the upload script purposefully doesn't append the file extension, but that's totally okay because the show_image.php script doesn't use the file extension either. So that's actually correct and you definitely don't want to add the .jpg extension to the uploaded file (for starters, what if the upload was a PNG?). 

    Normally if you're getting this result it's because your path to the file is incorrect. That your upload script uses ../../ch19_uploads/$id but show_image.php uses ../ch19_uploads makes me think that's the problem (assuming show_image.php and the upload script are in the same folder). Again, I definitely wouldn't move the folder, I'd just make sure you get the file path correct in the code. You can also try using an absolute path to the folder in your code. 

    Mysqli_Num_Rows() Expects Parameter 1 To Be Mysqli_Result, Boolean Given Array

    in Effortless E-Commerce with PHP and MySQL

    Posted

    It's not a matter of secrets. Forums like these or Stack Overflow are here expressly to share information and to help others. Honestly, the absolutely best thing to do would be to use mysqli_error() b/c then MySQL will tell you what the problem is, whereas we're just guessing. But without that knowledge my best guess would be that the PHP user for the script doesn't have execute permissions to run the stored procedure. Or you have the database wrong. In either case, mysqli_error() should tell you the actual cause.

×
×
  • Create New...