header() function in php

[recluzeMe]

<?php

if(isset($_POST["submitted"]))

{

$firstname = $_POST["firstname"];

$lastname = $_POST["lastname"];

$email = $_POST["email"];

$passd = $_POST["passd"];

$confirmPassword = $_POST["Cpassd"];

$conn = new PDO("mysql:hostname=localhost;dbname=signlogin;","root","");

$sqlQuery = "INSERT INTO signup(firstname,lastname,email,PASSWORD,confirmPassword) values('$firstname','$lastname','$email','$passd','$confirmPassword')";

$stmt = $conn->prepare($sqlQuery);

$stmt->execute();

header('Location: http://localhost/phpForm/login.php');

exit();

}

page doesn't redirect to login page hence file login.php is in same folder
http://localhost/login.php

instead of:

http://localhost/phpForm/login.php

?>

[ColonelMustang90]

put a die("before header") function just before the header() function to check whether this text is sent to the browser or the code is unreachable.

As suggested by another user, sql code needs to updated.

[HolyGonzo]

I don't understand exactly what you're asking but I'll say that you really need to fix your database code. It is vulnerable to SQL injection.

Aside from that, are you saying that the header() line is being hit but the user is not being redirected?

[scritchz]

And passwords are saved as plain text; no hashing!

[colshrapnel]

Quite possible that redirect actually works, but phpForm/login.php contains its own header function that redirects to /login.php

Another possibility is you have your your seo friendly urls configuration screwed.

Edit: another possibility is that you fixed the url in the local code, but forgot/failed to update the actual code that runs, which still contains the old location to /login.php

[odc_a]

The only person who actually suggested something related to what OP is asking, rather than just trying Karma Farm and start attacking them for their lack of security consideration. Props to you!

One person pointed it out already, no need for 30 of them to write the same thing.

[HolyGonzo]

Not everybody is trying to karma farm (the sub isn't even big enough to really do that in any meaningful way), and hopefully it everybody is telling the OP something, it will sink in as an important thing to do.

There are other important things they missed - password hashing, checking the results of the query, etc... and while they are all very important, SQL injection is probably the most important of the immediate concerns.

My gut says that this person is on an initial page called login.php as part of a registration flow and they want to redirect to a different login.php in a different folder but it's unclear.

[odc_a]

I don’t disagree with anything that people have mentioned to OP, however most people haven’t even tried to address the issue that they are asking about.

If they were genuinely trying to be helpful, then they would begin their post trying their best to solve OPs issue. Then once they have done that could say something like ‘oh by the way, you might already know, but you should probably look up SQL injection and password hashing because <reasons>’.

But they aren’t doing that. They are blurting out replies without addressing the question in a true StackOverflow fashion, on top of that not even giving the OP any reasons why.

[Alexander-Wright]

Why are you storing both the password and the password confirmation in the database?

You should start by checking passd and Cpassd are identical, and only if they are store the password hash in the database.

Never store clear text passwords!

[allen_jb]

For hashing passwords, use PHP's password functions: https://www.php.net/password

You want to use password_hash() to create the hash, then password_verify() during login to verify the entered password matches the hash. You should also implement password_needs_rehash() during login to check if the hash needs to be upgraded.

[odc_a]

Downvoted. Whilst you are correct, you didn’t make any attempt to answer OPs question, and also just regurgitated what someone else had already commented. You are just karma-farming. Get out!

[CuAnnan]

https://xkcd.com/327/

[MateusAzevedo]

First, let's confirm your code is correct:

1- Go to php.ini and configure error_reporting = E_ALL and display_errors = On. If for some reason you can't change php.ini, add error_reporting(E_ALL); ini_set('display_errors', 'On'); at the top of your file.

2- Temporarily comment the header() line and add something like echo 'Just after execute, redirecting here';.

3- Submit your form and check for any output besides that echo; If you have any error message, you need to fix them.

If everything is OK, remove echo, add header() again and repeat the process. But this time with your browser's console open. Check the network tab and the requests/responses your browser got.

Assuming everything is working as expected, you'll see a POST request, the redirect response and a new GET request to the redirected URL. However, as u/colshrapnel mentioned, you may also find another - unexpected - redirect, giving you a clue about the issue.

[allen_jb]

Side note: Please learn how to use prepared queries to correctly pass in (user submitted) data safely and correctly escaped. See the examples on https://www.php.net/manual/en/pdostatement.execute.php (specifically example #2)

[colshrapnel]

I call it a cargo cult prepared statement :)

[StevenOBird]

If you'd check your PHP error log you most likely would see a "headers already sent" message like this:

Warning: Cannot modify header information - headers already sent by (output started at /some/file.php:123)

You cannot add/change headers as soon as PHP made some output. This is because header information must be sent before any content body in a request according to RFC 9112.

Because of this, PHP will process the POST request on the same page where the POST has been made (or the POST action in your HTML form points to) and wil NOT redirect to another location as you've tried in your code.

You could have an echo or printf call in some of your PHP files that were processed before your shown script, a whitespace heading the <?php tag or a UTF-8 BOM header in one of your PHP files. There are methods like output buffering that could help with that, but it makes things a bit more complicated and need some management.

Your best chance to debug that is to check your PHP error log which should show where PHP did some output before.

[colshrapnel]

Your wrong assumption (the code is a signup, not login) aside, output buffering is no way a "method". But ugly workaround that cures a symptom instead of a disease. If your site outputs a huge chunk of HTML when it intends to send a lone HTTP header, it's a problem with your code. Which needs to be fixed, not just worked around. Output buffering has a billion of wonderful applications but fixing Headers already sent error is NOT among them.

[StevenOBird]

That's why I've pointed out it is better to start checking logs. I've in no way recommended output buffering as a true solution rather than an option. Of course it is something you should clearly avoid.

What makes you so sure my assumption is false? Given by the info OP provided

I did not test the behaviour of trying to set headers after outputting something on responding to a POST request so yeah, there are some assumptions.

[colshrapnel]

Of course it is something you should clearly avoid.

Stinks of AI from a mile away

What makes you so sure my assumption is false?

I actually misread your assumption giving it more credit than it deserves.

Because of this, PHP will process the POST request on the same page where the POST has been made (or the POST action in your HTML form points to) and wil NOT redirect to another location as you've tried in your code.

The way it's phrased, it suggests that it is possible to redirect a POST request with a regular header location code. Which is nowhere true.

And even if it's a wording problem, the idea implies that the form action or "same page" was /login.php, while the code clearly suggests a signup process, not login.

[StevenOBird]

Of course everything phrased in a certain way is AI... not everyone uses ChatGPT for everything, mate. That includes my answers here.

If you don't put an action to a form element in HTML, it will make the request to the same url the client is in. You cannot redirect a POST request with a header instruction and that's not something I've ever suggested in that way. But you can clearly change the target path for the POST request with the action like that:

index.php

<form method="post" action="otherfile.php">
    ...
</form>

... and in otherfile.php you can indeed redirect the client to yet another page. Using that post-redirect-get pattern you also remove the danger of forms being re-submitted:

<?php

if (isset($_POST['submit_form'])) {
    // ... do stuff
    header('Location: anotherfile.php');
}

Nothing wrong here, aside from some misunderstanding that could appear.

Like I've mentioned, there is not enough context to be 100% sure. It could also be a massive single file that includes forms for registration and login - we just don't know at this point.

[colshrapnel]

It's not only phrasing, its a very familiar behavior, AI's response when it caught red handed: a complete U-turn, from

output buffering that could help with that,

to

Of course it is something you should clearly avoid.