Larry

Ugh, this is an annoying type of problem! Basically HTML QuickForm can't find the resources it needs, which either means they weren't installed OR they were installed but HTML QuickForm can't find them. If it's the latter, that's normally b/c the files weren't installed in the right location OR PHP isn't looking in the right location. What steps did you take to install HTML QuickForm?

There's no SQL in the .DS_STORE file. That's a remnant from the Mac OS. You can ignore it. All of the SQL commands are found in files with a .sql extension.

I'm not sure I'm following exactly but just to confirm, is your server properly set up to send emails?

Wow, I never would have gotten there! Kudos for figuring it out and thanks so much for sharing the solution!

Ah, kudos for figuring it out and thanks for sharing your journey with us!

Unfortunately I don't have any experience with IIS rewrite rules. Perhaps this is something your professor could help with? If you're having this problem, certainly other people in the class will be, too.

Thanks for the nice words! Yes, as a general security rule you don't want user-uploaded files in the web directory. It would make sense to create a new folder for each user and store their uploads in their own directory. Some OSes have limits on the number of files or folders than can be in a directory, so that's a problem you'll need to worry about should you get to a high level. To show, say, an image in the browser, you'd set the HTML src to something like image.php?id=X. The image.php script would identify the image to be served and output it. I forget if there's an example of that in this particular book but it's not that complicated.

Glad it's working and thanks for letting us know. If you have any additional questions or problems with this particular issue, post them in this thread. If it's a new concern, a new thread works. Also, while oversharing details is better than undersharing, I don't think anyone's going to download and look through a folder of code. Best just to put all the context in the post itself. Good luck with your class!

The general site resources--images and such--are referenced in the header file, so the HTML there needs to be correct. In your case, they need to start with the "/homework/ex2/html/ " bit. The HTML for images for specific products is created by the PHP scripts, like shop.php and browse.php. You need to make sure those scripts are outputting the correct HTML, including the "/homework/ex2/html/". As a debugging tip, if your dark_roast.jpg image is in the "<webroot>/homework/ex2/html/products" folder on your computer, the proper HTML reference to that image is "/homework/ex2/html/products/dark_roast.jpg". You can confirm this but loading http://web260.local/homework/ex2/html/products/dark_roast.jpg directly in your browser. Once you have the right HTML to view an image directly in your browser, you know you have the right HTML to put within your code.

I'm not sure what you mean by "secondary links" but if you're seeing broken images, the HTML references to those images are likely incorrect. The image should not be affected by any rewrite rules. What is the URL you're using to test locally (for a page that works)? What HTML are you using for one of the links that's broken? Where are the images stored locally?

This is a common issue when first starting with sessions. It'll take a bit of debugging work to figure out where the problem is. Often the cause is inconsistent subdomains--www.example.com to example.com--but if you weren't having a problem with cookies, this isn't likely the cause. Working this backwards and looking at the code, here's the key bit of loggedin.php: session_start(); // Start the session. // If no session value is present, redirect the user: if (!isset($_SESSION['user_id'])) { So you're _only_ going to be redirected if there is no stored $_SESSION['user_id'] value. There's just two causes for that: The session has changed (i.e., the value isn't stored in this session). The session has remained the same but the value wasn't properly stored (e.g., used the wrong code). To debug the first, print out the session ID or look at the session cookie value on each page. Because of redirects, you'll want to do it like so: echo session_id(); exit(); If the session ID isn't changing, then it's probably just a typo somewhere in the storing or referencing the $_SESSION['user_id'].

Oh, ah, sorry for confusion! You could name it anything in the URL; it could be "chuck=57". It's the PHP code that then uses this value and knows what to do with it (i.e., you the programmer make the correct association). It's not a big deal in this case but generally you don't want to reveal database details publicly. Hence, "id" is ever marginally more generic than using "user_id".

Two primary issues, one minor: - (Minor) You call the function with echo but the function itself prints, so this is redundant. - You really should use global variables in a function, for the most part. Functions should be passed the data they need.

You've missed the initial double quote for the href value, which could be the cause of this. Debugging this is pretty straightforward and you've been doing good detective work. The error you're seeing is b/c either $_GET['id'] or $_POST['id'] isn't set or isn't numeric. The first time the page is loaded is a GET request, so you can ignore the POST bit. So now you can check whether there is a *numeric* id value passed in the URL. Assuming you're testing the script/code you think you're testing, the ONLY possible explanation is that there's not $_GET['id'] or there is one but it's not numeric. You said that the url included "?=57", which means there's no "id" being passed. Although that may have been a typo in your post here. My hunch is the lack of an opening " in your view_users.php script means the actual URL in the browser has an extraneous closing ", making it read edit_user.php?id=57" or edit_user.php?id=57&quot; In both cases $_GET['id'] is not numeric.

I'm not sure I follow exactly what you're asking but I'll try to answer as best as I can... First, a constant would be better than using a hardcoded number--65--that has no context and can easily be lost within the code. The constant allows you to "label" the value and makes it easier and more obvious to change down the line. Second, the next prompt suggests taking the average speed as user input instead of using the hardcoded number or a constant. So you'd just repeat what the calculator does with distance but for the average speed.

Thanks for the nice words and for the interest in my books. It is appreciated! I discuss PDO in my PHP Advanced book, however that was last published in 2013 and I'm sure I didn't cover all the functions. Since you're already using PHP, maybe try giving the PHP manual a go first?

Ah, excellent. Glad we figured it out and thanks for letting me know!

Ah, okay, so it could definitely be possible that you're just not running the code you think you're running. Specifically: you're still submitting the form to the older version of register.php, which does not mysqli_real_escape_string(). That would solve this mystery.

Sorry, I should have been more clear. The original else clause for handling the last name is this: } else { $ln = mysqli_real_escape_string($dbc, trim($_POST['last_name'])); } Replace that with what I previously posted and then fill out the form--using an apostrophe in the last name value--and submit the form to see the results. But that mysqli_get_charset() returns nothing is informative already. The problem isn't going to be with your HTML form. The values are getting to PHP fine, they're just not being escaped by mysqli_real_escape_string().

Sorry for the delay; this is a super random issue that I've never seen before. I'm not finding anything relevant in Google searches, either. Yes, you can use prepared statements, which don't use mysqli_real_escape_string() at all. That's totally fine, if not a better end result. If you want to continue debugging this, change your code to this, try it, and let me know what the result is: } else { echo '<p>Submitted last name: ' . $_POST['last_name'] . '</p>'; echo '<p>Established charset: ' . mysqli_get_charset($dbc) . '</p>'; $ln = mysqli_real_escape_string($dbc, trim($_POST['last_name'])); echo '<p>Processed last name: ' . $ln . '</p>'; }

Ah, okay. First, you definitely DO NOT store the hashed password in the cookie. The password may be the most important thing to protect, period, especially since users often re-use passwords (i.e., you wouldn't just be compromising their security at your site, you'd be compromising it at other sites potentially as well). "Keep me logged in" is just a matter of extending the session beyond its normal, short length. The specifics of how you do this depend upon how you manage sessions but the basic idea is: 1. Store the session ID in a cookie with a longer expiration. 2. Store the session ID and session data in a database so the session can be recreated. Note that the default PHP session behavior is for everything--cookies, data--to be deleted relatively quickly, so you can't just rely upon that for the extended session.

The premise is pretty simple: if the user checks the "Remember Me" box you send an additional cookie with a longer expiration and a unique identifier. When the user returns, if the cookie still exists, the unique identifier can then be used to pull their username or email address from the database and prepopulate the form with it. In terms of security, just be sure that the cookie value isn't easily reverse-engineered. For example, storing the user's ID or email address or some similar unique identifier in plain text would be the worst possible thing. Storing a hashed version is slightly better, but still not great. Better yet would be to create a table that stores the random hash tied to the user's record (in the database). Then store this hash in the cookie. With each login, create a new hash (in the database and in the cookie).

You have a syntax error in your connection script: "my_sqli_connect..." Working backwords, mysqli_real_escape_string() won't work--won't escape an apostrophe--if it doesn't have access to a database connection with an established CHARSET. To the problem should be either with the database connection or the charset not being set. First, fix the syntax error and then try again. If that doesn't work, print out the value of $dbc to confirm that it's an object. If it has a false value, that's a problem. If you're still not seeing the cause, connect directly to MySQL using the terminal (command line) to confirm your values. And thanks for the nice words on the book!

Okay, in looking at ZF, as of a year ago it's now been converted to an open source project: https://framework.zend.com/blog/2020-01-24-laminas-launch So in a production environment you'd use Laminas mail, not ZF (https://docs.laminas.dev/laminas-mail/). It should be secure and efficient enough and would work in a hosted environment. Another alternative is to use a third-party email service like Mailgun or Sendmail. Both cost money but provide additional features, such as detailed logs, protection from spam (i.e., your mail server being used to send spam), greatly improved success in an email being accepted, etc. Mailgun is only like $20/month for 1k emails, if I recall correctly. These make sense if you're willing to spend a bit more money up front and don't want to run your own mail server at all.

This is very weird. You've done good detective work but it doesn't seem like mysqli_real_escape_string() is doing what it's supposed to be doing. I'm kind of guessing here, but mysqli_real_escape_string() requires that the CHARSET is established. I'd start by making your your MySQL connection script does that. mysqli_set_charset($dbc, 'utf8');