Page 1 of 1
Not understanding variables
Posted: Sat Aug 01, 2009 1:35 pm
by ybot1122
Hi, I tried to create a registration form without MySQL (stored in txt files).
Here's the idea:
Registration Form => Check the Form (using separate script) => Return to Original Registration Form with Errors Highlighted
During the "Check the Form" process, several variables are defined.
ex.
Code: Select all
if (empty($_POST['username'])) {
$problem = TRUE;
$nousername = TRUE;
}
When we return to the registration form, I want the variables to retain their definition from the previous process.
ex.
Code: Select all
if ($nousername == TRUE) {
echo"No Username Entered";
}
I can't get this to work, and have no idea how to accomplish this. I keep getting "Undefined Index" notices on the last step.
Re: Not understanding variables
Posted: Sat Aug 01, 2009 5:10 pm
by Jammerious
I think you want to automatically enter the info that was submitted with the form, even though you have errors there. So you need to assign these values to the controls, for example, textboxes have a proprety named "value":
Code: Select all
echo '<input type="text" name="foo" value="' . htmlentities($_POST['foo']) . ' />';
Though I am still not sure htmlentities covers all the bases, to prevent XSS attacks. Maybe some of the more experienced guys can comment on this.
Re: Not understanding variables
Posted: Sat Aug 01, 2009 5:13 pm
by Eran
XSS is not a concern when you are replaying the user his own content. Unless he wants to attack himself
Re: Not understanding variables
Posted: Sat Aug 01, 2009 5:20 pm
by requinix
Agreed, but it is possible for a bad person to craft a POSTed form and have a good user accidentally submit it.
Also, htmlentities (and htmlspecialchars) will protect your HTML from someone putting a " in the value. Otherwise you'd have
Code: Select all
<input type="text" name="foo" value="some value with a " in it" />
(Just remember that if you use 's around attribute values instead of "s then you need to pass ENT_QUOTES to htmlentities, because by default they're not escaped.)
Re: Not understanding variables
Posted: Sat Aug 01, 2009 5:26 pm
by Eran
The protection against "crafting" the form is by checking that it is submitted from the same site (using a token), not by filtering the content. In some cases it would be a mistake to use something like htmlentities (textareas) since that would change the content, especially on several consecutive submissions
Re: Not understanding variables
Posted: Sat Aug 01, 2009 6:01 pm
by requinix
pytrin wrote:The protection against "crafting" the form is by checking that it is submitted from the same site (using a token), not by filtering the content. In some cases it would be a mistake to use something like htmlentities (textareas) since that would change the content, especially on several consecutive submissions
I, for one, don't like using things like tokens unless they serve a second purpose - they're merely there for handling the form. Same for giving names to submit buttons and using that to check if the form was submitted.
I'm curious as to when htmlentities would be bad. All it does is encode the data into something that can be represented as a single string without including unwanted markup or breaking surrounding markup.
If you htmlentities() something into a textarea and it is sent back without changes, PHP will receive it as normal text - no entities included. If
Code: Select all
echo "<textarea name='text'>", htmlentities($value), "</textarea>";
and the text is not changed, $_POST["text"] == $value will hold for any $value (barring text encoding problems).
Re: Not understanding variables
Posted: Sat Aug 01, 2009 6:13 pm
by Eran
Whether you like them or not, session tokens are a very effective way to deal with XSS. This has no relation to giving names to submit buttons.
Regarding the html entities - often you want to preserve the original content as is, without manipulation. Not every piece of content goes to a HTML page later
Re: Not understanding variables
Posted: Sat Aug 01, 2009 6:29 pm
by requinix
pytrin wrote:Whether you like them or not, session tokens are a very effective way to deal with XSS. This has no relation to giving names to submit buttons.
I know, I'm not disputing that. I just prefer doing it differently.
Named submit buttons are unrelated but serve a similar purpose: a "flag" of sorts that lets you know something specific about the form as it was submitted.
pytrin wrote:Regarding the html entities - often you want to preserve the original content as is, without manipulation. Not every piece of content goes to a HTML page later
Right. Which is why you are not supposed run something like htmlentities on text when storing it to a database; instead, you run htmlentities on it just before it's being outputted (on an HTML page).
Using htmlentities when putting something into a textarea isn't modifying the text - if anything it preserves it by making sure that the text retains the literal characters it has without some being interpreted as markup.
Re: Not understanding variables
Posted: Sun Aug 02, 2009 5:39 am
by Jammerious
pytrin wrote:The protection against "crafting" the form is by checking that it is submitted from the same site (using a token)
If you can spare a minute or so, could you explain what do you mean with form tokens, and how to practically apply them?
I believe you are not reffering to have a list of expected form fields against which you can validate?
Re: Not understanding variables
Posted: Sun Aug 02, 2009 6:23 am
by requinix
Jammerious wrote:If you can spare a minute or so, could you explain what do you mean with form tokens, and how to practically apply them?
A form token (or whatever people want to call it) is where you attach a unique, one-time identifier to the form. You also put it into a place that only your code can access. This way you can check for the identifier from the form and if it matches what you have "on file" then you can be very sure that the form submission came from your site/code and not somebody else's.
Code: Select all
<?php // page that generates the form
session_start();
// ...
$token = sha1(uniqid(microtime(), true)); // unique token for the form
$_SESSION["user record lookup form token"] = $token; // store for access later
echo "<form action='/path/to/page.php' method='post'>\n";
echo "<input type='hidden' name='token' value='{$token}' />\n";
echo "<p>Get records for user #<input type='text' name='userid' size='10' /> <input type='submit' value='Go' /></p>\n";
echo "</form>\n";
Code: Select all
<?php // page that receives the form ("/path/to/page.php");
session_start();
if (!isset($_POST["token"], $_POST["userid"], $_SESSION["user record lookup form token"])) {
// form was not submitted or we do not have the form token
} else if ($_POST["token"] != $_SESSION["user record lookup form token"]) {
// token does not match what we have
} else {
unset($_SESSION["user record lookup form token"]); // remove the token so it can't be used again
// do our work
}
OILF ("out in left field", because most of this thread is off-topic already ):
Jammerious wrote:I believe you are not reffering to have a list of expected form fields against which you can validate?
If I understand you, that's what I'm talking about regarding submit buttons. Instead of checking that the submit button is present in $_POST and (if so) assuming everything is okay, I check that all the expected fields are present (and validate). You can see this in the example code I posted: the submit button isn't named and I use
isset to check that each field individually (all two of them, plus the session token) exists.
The alternative is to name the submit button and have
if (!isset($_POST["name of submit button"])). However even if *I* did that *I* would check that each required field is present
anyways so really there wouldn't be much point to the whole thing.
edit:
Back on-topic, because I'm not too sure the original question ever got answered:
You can't define variables on one PHP page and have them appear on another PHP page without doing some work.
Best way for you, here, is to put those values into the session. One method would be like this:
Code: Select all
session_start();
// ...
if (empty($_POST['username'])) {
// form these in the negative: "do not have X" or "problem with X" rather than "do have X" and "X is okay"
$_SESSION["problem with registration"] = true;
$_SESSION["registration form missing the username"] = true;
}
Code: Select all
session_start();
// ...
// use !empty($_SESSION["..."]) to check if a flag is set, then unset() if it is. example:
if (!empty($_SESSION["registration form missing the username"])) {
echo "No Username Entered";
unset($_SESSION["registration form missing the username"]); // we don't want to reuse this next time the form is submitted
}
Re: Not understanding variables
Posted: Sun Aug 02, 2009 7:22 am
by Jammerious
Sorry for the offtopic; so as you nicely explained it, you are just making sure the form has been submitted from your site, to prevent for example other sites to use your forms and stuff. Basically this is the thing you want to have on search forms.
Re: Not understanding variables
Posted: Sun Aug 02, 2009 12:41 pm
by jackpf
pytrin wrote:In some cases it would be a mistake to use something like htmlentities (textareas) since that would change the content, especially on several consecutive submissions
That's not true - browsers will submit all POST data html decoded. That includes textareas...
If you have unencoded content in a textarea and validate the page, you will get errors. You should always run htmlentities() on user submitted data you plan to show back to them, or someone else.
Re: Not understanding variables
Posted: Sun Aug 02, 2009 3:19 pm
by Eran
validation errors on a form submission? how is that relevant to anything. do you think the user will be running validation tests after he submits the form?
As tsairis mentioned, the problem happens when you deal with multibyte characters. Not all of those are translated properly as the coverage of UTF support in PHP is incomplete (and by the way, you should use the charset identifier always since the default is ISO-8859). I personally have dealt with problematic characters many times since my local language (Hebrew) is one of the more problematic to work with in PHP.