Login - Jit4All

A login form is written with method="post", and the PHP file that receives it reads the submitted password using $_GET["password"]. Typing the exact right password and submitting it always fails the check, every single time, with no PHP error at all. Why would a correct password fail silently, instead of producing any kind of error?

$_GET only holds values that arrived as part of the address itself, after a ?. A method="post" form sends its values in the request body instead, which PHP makes available in $_POST, not $_GET. Reading $_GET["password"] after a POST submission finds no such key at all. PHP treats a missing array key as empty rather than as an error, so the comparison against the typed password simply fails, with nothing in the program's behavior pointing directly at the real cause.

A <form> tag's method attribute decides where the browser places the values it submits. method="get" puts them into the address itself, while method="post" puts them into the request body instead, out of the visible address entirely.

PHP makes submitted values available through two separate arrays: $_GET for values that arrived in the address, and $_POST for values that arrived in the request body. Reading from the wrong one finds nothing, not an error.

isset() checks whether a given key exists in an array at all. It answers a different question than checking whether that key's value happens to be empty, since a key can exist and still hold an empty string.

$_SERVER["REQUEST_METHOD"] holds the exact method used for the current request, as plain text such as "GET" or "POST", which lets one single PHP file tell a plain visit apart from an actual form submission.

A value typed by a visitor still needs htmlspecialchars() before being printed back into the page, for exactly the same reason covered earlier in this course, regardless of whether it arrived through $_GET or $_POST.

<?php
$errors = [];
$email = "";

if ( $_SERVER[ "REQUEST_METHOD" ] === "POST" )
{
    $email = trim( $_POST[ "email" ] ?? "" );

    if ( $email === "" )
    {
        $errors[] = "Email is required.";
    }
}
?>
<form method="post">
    <input type="text" name="email" value="<?php echo htmlspecialchars( $email ); ?>">
    <button type="submit">Sign up</button>
</form>

<?php foreach ( $errors as $error ) { ?>
    <p><?php echo htmlspecialchars( $error ); ?></p>
<?php } ?>

$_SERVER["REQUEST_METHOD"] holds the exact method used for this specific request. Checking it before reading $_POST at all means the validation code only runs once a form has actually been submitted, not on a plain first visit to the page.

trim( $_POST["email"] ?? "" ) removes leading and trailing spaces from whatever was typed, so a value that is only spaces, which would otherwise pass an empty-string check, is correctly caught as empty too, after trimming reduces it down to "".

$errors[] = "Email is required."; appends one message onto an array that started out empty. Reusing the exact same pattern for a second, different validation rule simply adds a second message onto the same list, without needing to redesign anything.

The value attribute on the <input> tag is filled back in with $email, run through htmlspecialchars() first. Without this, a failed submission would reset the field back to empty, forcing a visitor to retype something they already entered once.

The foreach loop over $errors only ever produces output when $errors actually contains something. On a first, plain visit, before any submission, $errors stays exactly as it started, an empty array, so that loop runs zero times and prints nothing.

Reading $_GET["email"] after a method="post" form submission does not produce a PHP error of any kind. It simply finds no such key, behaves as if the value were missing, and a validation check built on top of that fails in a way that looks exactly like the visitor typed nothing, even when they typed something correct.

isset( $_POST["email"] ) ) returns false specifically when that key does not exist at all in the submitted data. A field that exists but was submitted completely empty still makes isset() return true, because the key is present, just holding an empty string, a different situation from the key never being sent at all.

A visitor pressing the space bar a few times in a required field produces a string such as " ", which an untrimmed === "" check treats as a real, non-empty value. Only running it through trim() first reduces it down to the empty string this validation is actually trying to catch.

Printing $email straight back into the value attribute, without htmlspecialchars(), lets a visitor type a quotation mark followed by their own attribute or tag directly into that one field, breaking out of the value attribute entirely and inserting markup of their own choosing into the page.

Changing only the method="post" attribute on a <form> tag to method="get" moves every one of that form's submitted values from $_POST into $_GET on the very next submission, with no change required anywhere in the rest of the page except wherever the PHP code reads them back.

When an AI tool writes code that reads a form, three things are worth checking. First, does it read $_POST or $_GET to match the exact method attribute on the actual <form> tag it is paired with. Second, does every value pulled from $_GET or $_POST get escaped with htmlspecialchars() before being printed back, especially inside an attribute such as value="". Third, does a required-field check run the value through trim() before comparing it to an empty string.

Change the form's method attribute from "post" to "get", without touching the PHP code at all, submit it, and explain why $email stops being filled in.

Add a second validation rule, checking that the email contains an @ character using str_contains(), and append a second message onto $errors when it does not.

Add an isset( $_POST["email"] ) ) check before the trim() line, and explain what specific situation this extra check protects against that the existing code does not.

Trusting that a field marked required="required" in the HTML itself means the PHP code never has to check it again. A visitor can submit a form directly, bypassing the browser's own form entirely, with that field left empty.

Checking only whether $_POST["email"] is set, with isset(), and treating that as proof the visitor actually typed something, when an empty but present field passes that exact same check.

Forgetting that file uploads from a form do not arrive in $_POST at all. They arrive in a separate superglobal, $_FILES, even when the rest of the form's regular fields are read from $_POST correctly.

You can now match a form's method attribute to the correct superglobal in the PHP that reads it, and you can tell the difference between a value that was never sent and one that was sent empty. You also have a working pattern, checking the request method before validating, that keeps a plain first visit to a page separate from an actual form submission.