Header Problems and Basic PHP Question

Question

Hey,

I've been working on a site that I've been planning for awhile. It's a pretty big one, and I'm learning pretty much everything along the way. I'm having a few problems, so I figured I'd ask a couple of question here.

The first thing I'm having trouble with is I can't seem to figure out why this section of php is firing the header, and sending me back to the index page even though I've typed something in all the fields.

<?php
session_start();
if(!IsSet($_POST['userName']) || !IsSet($_POST['password']) || !IsSet($_POST['password2']) || !IsSet($_POST['email']) ||!IsSet($_SESSION['securityAnswer'])|| !IsSet($_POST['userAgreement']) || !IsSet($_POST['AUP']) || !IsSet($_POST['securityQuestion'])
{
$_SESSION['error'] = "You forgot to fill in one of the fields.";
header("Location: ../../index.php");
exit;
}
?>

PHP:

Also if you see any other errors please let me know.

Also this line of code when placed in there gives me an error of some kind, but can't remember what it is.

session_register("error");

Is there a continuation character like / in C++ that tells the comp that the code continues on the next line...

One final question. I'm a little worried about security, and plan on protecting myself from sql injection, but don't know when the problem starts. I have a form, and a register button...I'm thinking that injection can't happen right when they click the button because the programmer can't even process the information until the next script...so the injection must happen when the information is sent to the database by the web developer.... like say I didn't check bio text for injected code...when I send that bio to the database is that when the injection happens?

Thanks for the help in advanced, and hope all is well. Hope all was well in the woods Bucky

 

If you want to make sure all of the fields are filled (and just that, no checks for HOW they're filled, just do this:

<?php
session_start();
foreach ($_POST as $val) {
   if ($val == '') {
     $_SESSION['error'] = "You forgot to fill in one of the fields.";
     header("Location: ../../index.php");
     exit;
   } else {
     echo "blah";
   }
}

print_r($_SESSION);
//do something here
?>
<form id="blah" method="post" action="#">
   <input type="text" name="username" id="username">
   <input type="submit" value="send">
</form>

PHP:

This is just meant to show you how you can do it - you can of course do a recursive check on each of the $_POST-variables, and check for more than just whether or not they're actually filled, but that's a different topic.

 

Note that isset() can take multiple arguments, so you can do all in one single call.

if (!isset($_POST['foo'], $_POST['bar'], /* ... */))
{
    // Something is missing...
}

PHP:

Also, put this at the top of your script to see what input you're receiving.

print_r($_POST);

PHP:

... especially check for capitalization mistakes and such.

Oh, and session_register() is a deprecated function. Don't use it. If you want to assign values to your session, assign them directly to your $_SESSION array.

$_SESSION['foo'] = 'bar';

PHP:

As for your SQL injection concerns, you're going to have to post the code where you're actually saving the data. Otherwise we can only guess.

 

It'll be alright, I'll just test the input for special chars and the such. Thanks for all the info.

I'm just curious, how come the header line in the code that I have sends the user back to the homepage even if something is placed in the fields?

I'm definitely going to have to incorporate the loop, such a simper, and more robust way of going about it, lol.

Thanks again.

 

I noticed that in one of your isset() calls, you're using $_SESSION instead of $_POST. Not sure if that's intentional, but that could be the problem. If you're still having problems, do the suggestions above and see what you get.

As for the loop, keep in mind that the user can remove fields from your form before submitting it, and you're only checking if submitted fields are blank. So it's not completely reliable.

 

Thanks nico...not sure how that slipped by... probably a case of up till 4 in the morning coding, lol.

 

We've all been there. ;p

 

Coding while sleep deprived and/or drunk beyond belief always leads to immense amount of code. Sometimes it even takes less time debugging it than it would rewriting the whole mess

As for form-checking, I tend to end up with several hundred lines of code, both js and php unless I'm using ready-made classes or some framework, for creating code for taking care of all the different ways a user can f*ck up your form-content The above example was just a start. You can also automatically assign the $_POST-variables to the name of the $_POST - ie make $_POST['username'] into $username = _content_of_variable by doing something like the following:

$submittedcontent = $_POST;
foreach ($submittedcontent as $key => $value) {
   ${$key} = $value;
}

PHP:

This will assign the value of each $_POST-variable to the name of the $_POST-variable as $name_of_$_POST. It makes assigning the content to variables quicker, as long as you know the names of all of the variables.
The first assignment isn't strictly necessary, but I prefer it that way.

 

Ugh, I don't recommend doing the above, though. register_globals has been removed for a reason: it's not secure.

Especially someone new to programming should avoid lazy coding.

 

Uhm? Me? How is this in any way considered lazy or akin to "register_globals"? This only puts the $_POST-variables in a variable scope so you don't have to spell out $_POST['variable_name'] each time you wanna call it, but can just use $variable_name. I'm failing to see how that is in any way bad.

 

Well register_globals does (or did) pretty much what your code above does. If you follow the link from my other post, you'll see an example of why this is bad.

If you know what you're doing, you'll probably be fine. But new programmers should build up some knowledge on security before letting their users define local variables in their scripts. Note that the loop allows users to override existing variables that were declared before it. So unless it's the very first thing in your script, it's probably vulnerable at some point.

Hence register_globals has been removed. It's not a good coding practice.

 

Ah, yes. Of course that's true. I tend to process $_POST-variables in a specific sub-script - hence, scope is limited. To me, it's just a simpler and more efficient way to write out every $_POST-variable as a normal variable - post-processing is being done when using these variables, which I didn't post any code for - however, assigning variables, and using them after processing, is no worse than using $_POST-variables directly - however, I do see the thing about accidentally overwriting or assigning values to existing variables - but if that's a problem, you really need to look at your naming conventions

 

Awesome, I've actually got the script working thanks to the foreach loop. Ended up being pretty easy, but ended up bringing on a few new questions, but I need to post them in a new thread, because the questions are different.

Thanks for the help on this one