tags:

views:

85

answers:

3

All,

This question probably has a very simple answer - something I'm overlooking. But maybe someone can tell me where to look...

I have a PHP page ("index.php") with a very simple login form (e.g., username and password).

When the user clicks the "Submit" button, the form POSTs the values to another PHP page ("login.php"). That page is supposed to confirm the user's credentials, then do the following:

  • If the user's credentials are not correct, redirect the user to error.php, along with an error message
  • If the user's credentials ARE correct, create a session and set $_SESSION['authenticated'] = true, then redirect him to "loggedin.php"

[UPDATE]

Then, on loggedin.php, I check to see that isset($_SESSION['authenticated']) returns true. If it does, then proceed. If not, redirect the user back to index.php.

However, here's what happens. The FIRST time I fill out the form (with valid creds) and submit it, I can see briefly in the URL bar that the user is sent to login.php, then loggedin.php, but then BACK to index.php.

But, if I re-enter the same credentials and submit the info a SECOND time, everything works exactly as it should.

So, in short, it looks like either login.php is not setting the $_SESSION variable the first time through, or that it is, but for some reason, it's not set when I check it for the first time on loggedin.php

Is there some delay between setting the variable on login.php, and having isset() return true on loggedin.php?

Or, is there something else I'm doing wrong?

Here are the relevant (I think) snippets of code:

In login.php:

session_start();
$_SESSION['authenticated'] = true;
header('Location: http://www.mydomain.com/loggedin.php');

In loggedin.php:

session_start();
$authenticated = $_SESSION['authenticated'];
if (!isset($authenticated)) {
    header('Location: http://www.footballpoolz.com/mobile/index.php');
    die();
}

Many thanks in advance for any advice or insights!

Cheers, Matt Stuehler

A: 

Redirects really slow things down and cause extra server load. What you should be doing is posting back to the index.php page, which will detect if there is a POST or not. Then log the user in and display the contents of the loggedin.php file. No redirects necessary.

After all, you already know that the user is validated, why redirect them to another page where you have to check validation again (which you just did)? This is more of the concept of a "Front Controller" where your index.php acts as a router to load and display different pages. Even if it's just a welcome page when they login. This eliminates any issues with delays.

You are doing a session_start, right?

Brent Baisley
Leaving a POST without a redirect in the user's browser history makes BACK/FORWARD navigation confusing and causes forms to be re-posted with modal warning dialogs. It's good practice to PRG: Post/Redirect/Get.
dkamins
dkamins - Many thanks for your comment. Sorry - I'm new to most of this, but just to make sure I understand your point correctly, are you saying that it's good practice to post data from one page to a second page, and then have that second page redirect to a third page? And how/where does the GET come in?
mattstuehler
A redirect after a POST only adds an additional BACK step. You should still guard against double posts. Posting to a separate page makes it difficult to redisplay the form in case of errors. It also means 2 different URLs for the same form. The bottom line is that redirects are expensive.
Brent Baisley
+1  A: 

I think I may know the cause of the error. The session has to be linked to the browser and the IP address (this way more than one person can be logged in at a time). This means that the session has to not only be stored server-side, but the client has to have a link to the session as well so you know who they are logged in as when they request data. This session id is shared as part of the header during all HTTP requests.

When you're redirecting the user, though, you aren't giving them a chance to send new headers, are you? You're probably just sending them the new page. This new page never saw a header from them, so it doesn't know which session variable (PHP has hundreds or even thousands of session variables) belongs to them. When you log back in a second time, you are sending a header, and thus you're sending the session ID and PHP knows which session variable is yours.

There are two solutions. The first is to find a way to redirect them that forces them to send a new header. I believe using header("Location: www.mysite.com/newpage.php"); will do this. I may be mistaken.

The alternative is to temporarily pass the session id when you redirect them to loggedin.php so that you know they are logged in for that first page load. After the initial page load, you no longer need to take this extra step since it will be done for you every time they request a page. To pass the session id you just append ?SID=... to your redirect.

http://www.php.net/manual/en/session.idpassing.php

steven_desu
A: 

Instead of using this true . Try to put some value.

like $_SESSION['username']='mattstuehler'

and check

$loggeduser=$_SESSION['username']; if(!empty($loggeduser))

I dont see any bugs anyway

zod