Try out my first PHP web app!

[__]

This really needs to be fixed ASAP.

I’d say the same (twice) about the SQL injection vulnerability I mentioned earlier. Review all your code for similar problems.

[__]

UTF-8 is a character encoding… Characters such as », ¡ and • (the usernames I assume you refer to) are just as valid as an a is.

Yup. And just in case you’re wondering, UTF-8 is what you should be using.

If you only want characters that are considered “word” characters (i.e., not punctuation or symbols), you can use preg_match (like Soronbe suggested) with a regex like this: /^[\w]+$/. If you use [a-zA-Z0-9_]+, you’ll be excluding valid names like “Peña” or “Jörg”.

//make sure password contains no html tags

Beyond not being necessary, consider that passwords become both less effective and harder to remember with every character you disallow. The user also gets more frustrated each time they have to choose a different password.

die …why won’t it

I know every php tutorial/ example you come across uses die whenever something goes even a little bit wrong… but this really has no place on an actual web site.

die:

• is not a very nice way to present the user with an error message.
• usually leaves the webpage in an unfinished/broken state; e.g., with no functional site navigation or a broken layout.
• prevents you from catching/ handling the error in any way.
• prevents you from logging the error; you’ll never find out, and —if it turns out to be a problem with your code— will have no opportunity to fix it.
• does not let you control what/if should be output to the screen.
  (This can be a security risk, i.e., error messages from database functions often contain db credentials or other info that would be of great help to an attacker.)
• prevents you from doing any sort of cleanup: the script just ends abruptly.

Beyond that, @BenWalker’s got a great list of suggestions. Start looking through those and ask about anything you need more help with.

[__]

is there any other ways that stop the script, lets say on the register page, from registering the user and echo out the error message?

One thing to realize is that, for common error situations, stopping the script is completely unnecessary.

if( form_is_valid ){
    send_email();
    do_whatever();
    echo "Congrats!";
}
else{
    log_error();
    echo "You're a loser!";
}

For any action that you can do on your site, plan for each case. Things like picking a username that already exists shouldn’t be error-worthy. They should be pick-a-different-name-worthy.

I was thinking maybe creating a function that uses the die() but brings the user to a universal error page.

You could implement that quite easily, like so:

if( something goes horribly wrong ){
    header( "Location: http://your-site.example.com/error.php" );
    exit;  // scripts don't stop on their own
}

This still doesn’t allow you to handle the error in any way (e.g., log it, or try to recover — by the time your site goes “live,” most errors should be recoverable), but it makes the user experience much better. If you wanted to be able to pass specific content or messages, you could pass that info along (e.g., via $_SESSION).

what is the difference between die() and another function I have seen around called exit()?

die and exit are exactly the same thing. I prefer to use exit, because it is more descriptive of what it actually does. I use die when explaining situations where it is used incorrectly.

[__]

Sorry, didn’t see your follow-up post.

function error() {
die();
header("Location: error.php");
}

Two problems:

• In your example, the first thing you do is die.
  which means the second thing you do _won’t happen_.
• Location headers require absolute URLs. This is part of the HTTP spec. Your example will work in _most_ browsers, but not in all (and not necessarily consistently).

[__]

But without using the die function, the query will still run and the duplicate username will be created.

Two things:

First, yes — if you redirect the user to another page, you probably do want to stop the current script (but maybe not — for example, the original script might continue to do something not-user-output related, such as logging or finishing up other activities in progress.). If you look at my example above, we exit after sending the Location header. This is an example of a good use of exit/die. In fact, for the coding style/approach you’re using right now, it’s probably the only appropriate use.

Second, no — you’re talking about using die as a control structure. This is not what it is for. Control Structures define conditions, and instructions for what to do in each case. If you’ve got a situation where you something will happen, and you have two possible outcomes, an if…else structure might be a good solution.

pseudo-code:

if( username_already_exists ){
    echo 'This name is already in use. Please choose another.'
}
else{
    save_username();
    echo 'Thank you.';
}

The username_already_exists test would presumably return true if the username already existed, and false if not. The save_username function will only run in the latter case.

Note; this works well as an example, but BenWalker’s suggestion that you rely on the database to handle this check is the best way to go. Among other reasons, you will never have duplicate usernames, because the database will reject them.

[__]

But on my register page the if statements are backwards …

so, this

if( bad ){ don't do it }
else{ do it }

vs. this

if( good ){ do it }
else{ don't do it }

no problem.

[__]

// first, use placeholders in your SQL
$sql = "INSERT INTO forum ( post,post_title,post_date,posted_by ) VALUES ( ?,?,?,? )";

// prepare a statement from your sql
$stmt = mysqli_prepare( $con,$sql );

// bind parameters to your placeholders (make sure they're in the correct order)
mysqli_stmt_bind_param( 
    $stmt,
    'ssss',
    $_POST['posting'],
    $_POST['title'],
    $_SESSION['currentUser'],
    date( 'M-d-y' ) 
);

// execute the statement
$success = mysqli_stmt_execute( $stmt );
if( $success ){ /*  it worked  */ }
else{ /*  there was an error  */ }

[__]

"<input type='submit' class='posttitle' value='".$title."'>"

Say your post title was “You’re the Best”. If you put that $title into your html above, you get this:

<input type='submit' class='posttitle' value='You're the Best'>

The value is now “You”, there are three nonsense attributes (re, the, and Best), and then there’s an extra trailing quote. See the problem? How could you fix that?

[__]

So why is my list bad but htmlentities() isn’t?

Nothing’s “bad” about it per se. It’s not implemented, and a programmer might implement it incorrectly (or just partially). htmlentities is tried and tested and maintained (plus it’s native and will run a lot faster).

what is the difference between htmlenteties and MySQLi real escape string?

Conceptually, yes, they have similar purposes: to prevent “data” from being interpreted as “instructions.” But, because one deals with HTML and the other deals with MySQL, they do different things and work in completely different ways.

Read The Friendly Manual for specifics.

[__]

do I use the htmlenteties() function when submitting the title to the DB and then just pull that right from the DB to display it? Or vise versa?

There isn’t a cut-and-dry answer for that. For example, if you apply htmlentities to the post when you save it, then it will be impossible (or, at the very least, difficult and uncertain) to make a plain text version of the content (e.g., for an RSS reader, or to provide the content in JSON format).

In general, I save content in its original format, and apply htmlentities only when I’m ready to display it.

edit
actually, in most situations, I use htmlspecialchars instead. But in this situation, that doesn’t have any impact on how or why it is used, and the flag options and defaults are identical.

[__]

Flags: you got it. : )

As for html_entity_decode, I think my earlier comment may have led you in the wrong direction. To be clear:

You are displaying this in an HTML page. Anything you want shown as “plain text” should be html-entity encoded. Do not decode it before putting it on your webpage. When you serve un-encoded text to a web browser, the web browser treats it as HTML. HTML entities are the only way the browser knows that it is supposed to be plain text.

What I was talking about earlier were other formats, which are not parsed as HTML. This is not one of those situations. Sorry for the confusion.

[__]

So is the method in place right now incorrect?

When you have text that is supposed to be “plain text,” it must be encoded as html entities by the time it gets to the page.

Say you had a post titled “All About The <H1>Headings</H1>”. If you use htmlentities, it will look like this:

All About The & lt;H1& gt;Headings& lt;/H1& gt;

But when viewed in the browser it will look like plain text. If you decode that, then when it gets to the browser, it will look like this:

All About The

Headings

This is exactly what XSS attacks are about: confusing what is supposed to be data (content) with what is supposed to be instructions (HTML markup).

[nixnerd]

Ok I just had to stop in and see how large this has grown. Holy &%$* that’s a lot of posts.

People will use ugly sites if they’re useful (even if they’re not all that usable sometimes). Look at Craigslist or Reddit.

Yeah… I couldn’t agree more with this more. I for one REALLY appreciate awesome design and clean UI and an overall “pretty” experience. However… there’s no arguing with facts. Craigslist, Reddit and 4chan are some of the ugliest sites in the world and have arguably more cultural impact than all the “pretty” sites combined.

Ugly and functional sometimes wins. Look at the CLI… NO ONE has found a more efficient way to do things… so it lives on.

BTW: I am NOT a 4chan anon, nor am I a very frequent Redditor. Just stating facts. Hell, I don’t even really use Craigslist but for once in a while. But… people DO use these sites in droves.

[nixnerd]

Sidenote: The front page of Reddit = What will be on Good Morning America next week.

[nixnerd]

You could style the template up to be clean and usable in a few hours I would bet. It’s not that far off from the current flat design craze. Again… as long as it works and does what people want it to do… they won’t care. Designers (myself included) love to think otherwise… but it’s true. Now… design can ENHANCE the experience, but it doesn’t make it.

[Author]

Posts