Get INDEX error message once the page loads

[madlady37]

HELLO everyone.

Can some one help me understand this please.

I get a load of undefined indexs, when my page first loads, but when I do a refresh it goes away.

 

 

Here is my code.

The page Im a referring to is my login in page and my register page. These pages seems to have something in common with indexs.

 

My registration page code. I have strip_tags, striplashes, and mysqli_real_escape_string in place.

if(isset($_POST['register'])){
		include_once("db.php");
	//Define Variables
	$username = strip_tags($_POST['username']);
        $password = strip_tags($_POST['password']);
        $password_confirm = strip_tags($_POST['password_confirm']);
        $email = strip_tags($_POST['email']);
 	$email_confirm = strip_tags($_POST['email_confirm']);
 	$firstname = strip_tags($_POST['firstname']);
 	$lastname = strip_tags($_POST['lastname']);
 	$middlename = strip_tags($_POST['middlename']);
 	$suffix = strip_tags($_POST['suffix']);
 	$dateofbirth = strip_tags($_POST['dateofbirth']);
 	$address1 = strip_tags($_POST['address1']);
 	$address2 = strip_tags($_POST['address2']);
 	$city = strip_tags($_POST['city']);
 	$state = strip_tags($_POST['state']);
 	$county = strip_tags($_POST['county']);
 	$zip = strip_tags($_POST['zip']);
 	$cellphone = strip_tags($_POST['cellphone']);
 	$homephone = strip_tags($_POST['homephone']);
 	$worknumber = strip_tags($_POST['worknumber']);
 	$extension = strip_tags($_POST['extension']);

[ginerjm]

What you posted is no help for us to help you.

 

That said - the problem is most likely due to you outputting variables (arrays!) that have not yet been defined on the first pass thru your script. A properly structure page will do all the php logic first so that vars that need to be defined for the eventual output are actually defined. Then at the end of your script you generate your html output, which will then be outputting already-defined vars.

[Jacques1]

Several things:

• Strike strip_tags() and stripslashes() from your memory. Both functions are completely useless and will actually mangle the user input so that you end up with garbage data. It's great that you're appearently trying to make your code secure, but security techniques must be understood and carefully chosen for the specific context. If you just throw all kinds of random functions at the input, that's counter-productive.
• Don't repeat yourself. Writing down the same thing over and over again may be a great typing exercise, but it has very little to do with programming. When you encounter a repetitive task, you should ask yourself two things: Do I even need this? And if that's the case, how can I implement it in a smart way with abstraction and loops? In your case, you don't need this. Copying every POST paramater into a local variable is nonsensical.
• Validate user input. Don't just assume that all expected parameters are there.

A smarter approach:

<?php

// first declare all POST parameters we expect to get from the user
const REQUIRED_PARAMETERS = [
    'username',
    'password',
    'password_confirm',
    // ... you get the idea
];



// collect all error messages
$errors = [];

// Did we receive a POST request?
if ($_SERVER['REQUEST_METHOD'] == 'POST')
{
    /*
     * Check if all required parameters are present; note that I'm using a loop rather than writing down the same
     * statement over and over again
     */
    foreach (REQUIRED_PARAMETERS as $required_param)
    {
        if (!isset($_POST[$required_param]))
        {
            $errors[] = 'Missing parameter: '.$required_param;
        }
    }

    // TODO: Further validation if necessary

    if (!$errors)
    {
        // *Now* you can assume that the input is correct and start the actual processing
    }
}

?>
<!-- TODO: If there are error messages, display them on the page -->

[benanamen]

@Jaques1,

 

I like what you did with the foreach for missing parameters. That saves a lot of repetitive error checks.

 

In your example you go with if not errors continue/else show errors. Any reason not to do the opposite and go with if errors display them/else continue processing. Thinking in logical and positive order (if errors), if there are errors, it seems handling the errors would be step two and not step three. Does it even matter?

[Jacques1]

The error messages should just be passed to the template engine (or the lower part of the script) for rendering, so the validation procedure is done at this point. At most, you'd set the response code.

 

Also note that the above is meant for small applications. In more complex systems, you'll want a declarative approach where you only define the requirements and leave the actual validation to the framework/library. As in: “The e-mail is required, must match the e-mail pattern, is between m and n characters long ...”. Checking the requirements and displaying sensible errors is then done automatically.

[madlady37]

Thank you all for your  help I understand, and I apologize for not making my error clear.

[benanamen]

Correct me if I am wrong, but shouldn't this line 

 

if (!isset($_POST[$required_param]))

 

be

 

if (empty($_POST[$required_param]))

 

isset checks if a variable isset AND is NOT NULL

 

If the form is submitted without filling out a required field, the POST for that field will be isset with an empty string making it not null so it will never throw an error.

Edited November 15, 2016 by benanamen

[cyberRobot]

if (empty($_POST[$required_param]))

 

The empty() function also considers values like the number 0 as empty. That could be problematic with some forms.

 

With that said, I think the goal of Jacques1's code is to make sure the necessary parameters exist. Any validation beyond that happens elsewhere. If a field is required, you would run a second check to make sure the variable isn't blank.

 

I personally do something like this:

if(!isset($_POST['someVariable']) || $_POST['someVariable']=='') {
    //flag error
}

 

...which, of course, can be simplified with Jacques1's code.

Edited November 15, 2016 by cyberRobot

[Jacques1]

If a parameter isn't present at all, that's a much more fundamental problem than a blank field, so I would treat that differently and maybe even log it as an error. It probably means there's a defect in your application (it could also come from a broken client, but that's rare).

 

A blank field, on the other hand, is a perfectly normal user error.

Edited November 15, 2016 by Jacques1