Jump to content

Recommended Posts

Hi Guys,

 

Quick question.

 

I'm trying to get my head around how I would check that a user has reached a certain page from another page.

 

So for example, the workflow through my site is something like the following:

 

  • user registers
  • a verification email is sent
  • user clicks the link within the verification email to complete the sign up process
  • user logs in and ONLY on a successful login will the following happen:
  • checks are made to see if account has been verified
  • if user has been verified, go to main menu
  • if user has not been activated his account then he goes to a page that says account has not been activated

 

The bit i'm struggling to get my head around is this...

 

the user should only reach the page 'account has not been activated' page from the login page. If that page was called confirm-account.php. What can i do to stop a random person typing something along the lines of www.mywebsite.com/confirm-account.php and getting straight onto that page? or even upon the registration process if the user is taken to a page that says an email has been sent, how would i stop a random person just typing the url straight to that page and bypassing the pages I would expect them to have gone through before reaching that??

 

:shrug:

 

Cheers

 

 

 

How

1. User login

2. ? activate account – yes

3. Create the session

4. Go to main page

5. in the main page  validate the session

6. If the  validation failed  go to sign /register page

 

http://net.tutsplus.com/tutorials/php/user-membership-with-php/

Session Validation

http://stackoverflow.com/questions/4959551/php-session-validation-best-practices

So reading that the guy recommends using $_SESSION['LoggedIn'] = 1 to check that you have previously logged in...

 

I'm just wondering is that secure enough? Couldn't somebody create/mimic/fabricate that variable so that your site thinks you are already authenticated?

 

I was considering taking the username and password into session variables and simply checking that the session username and password match a record in the database, if it does then your logged in if not then you get redirected to a 'you must log in to view this page' page.

 

Which is better? secure and performance-wise?

 

Cheers

I was considering taking the username and password into session variables and simply checking that the session username and password match a record in the database, if it does then your logged in if not then you get redirected to a 'you must log in to view this page' page.

Yes you can use username for session.

Not password.

 

if you google 'session hijacking php', you will get some knowladge.

I was considering taking the username and password into session variables and simply checking that the session username and password match a record in the database, if it does then your logged in if not then you get redirected to a 'you must log in to view this page' page.

Yes you can use username for session.

Not password.

 

if you google 'session hijacking php', you will get some knowladge.

Stickin' the password in is still secure as long as it's not printed out anywhere.
Stickin' the password in is still secure as long as it's not printed out anywhere.

it like a leaving a front door open  :D

 

Try this code

<?php
    session_start();
    
echo "<h3> PHP List All Session Variables</h3>";
foreach ($_SESSION as $key=>$val)
    echo $key." ".$val."<br/>";

?>

Now you know  that why it is not advisable. 8)

Ok, so...

 

more worried and confused now!!

 

...can you tell me if this is secure?

 

[*]user enters username and password

[*]the form goes to logincheck.php

[*]I use _POST to get the username and password entered

[*]username and password is checked against the database

[*]if user exists and credentials are correct then:

[*]username is stored in username_session

[*]password stored in password_session

[*]every page after that calls those 2 session variables and then checks the database again to see if they match the user

 

I get what you are saying about session hijacking, i think... and I tried the code you posted which output the username and the hashed password.

 

How can I avoid this?

 

I am still unsure as to what to do now to ensure that it is a correct user logged in! I can see the benefit of having a session_logged_in == 1 now as that doesnt give a hacker someones password if they find a way to hijack the session or find out the data stored within the session but couldn't a hacker then just send a session_logged_in = 1 variable and the username and my system would just let them straight in???

 

Help! lol

 

Cheers

Ok, so...

 

more worried and confused now!!

 

...can you tell me if this is secure?

 

[*]user enters username and password

[*]the form goes to logincheck.php

[*]I use _POST to get the username and password entered

[*]username and password is checked against the database

[*]if user exists and credentials are correct then:

[*]username is stored in username_session

[*]password stored in password_session

[*]every page after that calls those 2 session variables and then checks the database again to see if they match the user

 

I get what you are saying about session hijacking, i think... and I tried the code you posted which output the username and the hashed password.

 

How can I avoid this?

 

I am still unsure as to what to do now to ensure that it is a correct user logged in! I can see the benefit of having a session_logged_in == 1 now as that doesnt give a hacker someones password if they find a way to hijack the session or find out the data stored within the session but couldn't a hacker then just send a session_logged_in = 1 variable and the username and my system would just let them straight in???

 

Help! lol

 

Cheers

 

Ok, i've been doing more reading and think that i am about there!! If I prevent against session hacking using a token type system and use the sessions: session_logged_in and session_username, then i can assume that the sessions are from the intended user. I think the following workflow should explain my understand a bit clearer:

 

  • user enters username and password into the login page
  • login script calls the variables from the form using _POST
  • user is authenticated
  • if user exists:
  • create a session ($_SESSION['LoggedIn'] = 1 and $_SESSION['Username'] = $username)
  • user is then redirected to membersarea.php

[*]on membersarea.php the script checks the sessions:

if(!empty($_SESSION['LoggedIn']) && !empty($_SESSION['Username']))

  • you are now logged in.
  • else you are redirected to a login page

 

Is that correct? I feel like I am blindly just assuming the session is valid and giving someone (maybe a hacker) free roaming access to this account.

 

1 last thing, previously I would have used sessions to hold the username and password and then re-authenticate everytime i hit a new page. If I use the method above (if it is indeed correct) when I query the database for the logged in users data (to take in his surname from the database into a variable for example) would I just use a simple

SELECT * FROM users_table WHERE username='$username'

(ignore the code, i've just typed this as an example).

 

Thanks

In order to tell a page you came from another page you need to append a get variable with the page name in it and have the other pages check if for that variable. Its best to encode the variables data into something decodeable so you can get which page sent the user to this page or you could add the $_SERVER['HTTP_REFERER'] variable which is send as a header and could then be check per page and reset but that can get tricky. Best bet is to expect a get variable and if it not found show standard page. No need fr sessions unless you require them to login.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.