Login currency and database

PHP
1

I’m at a point in my application where I’m trying to understand how to implement a user’s login status in conjunction to the database (MySQL). Simply put, when the user logs in, I want their status to be “logged-in” and when they click on the logout button or link, I want their status to then be “logged-out”. Pretty straightforward, right?

How is this usually handled? I keep thinking that it probably includes sessions and I have an initial foundation built for this, but I’m other than that, the only thing I can think of is some form of MySQL field boolean token that gets stored upon login/logout (something that would be easy to fool, needless to say).

Also, if there’s a time factor involved with this, what would be an acceptable amount of time for someone to be logged in when not actively using the website AFTER having already logged in?

Any insight into this is appreciated.

2

what I do normally to log a user in is along these lines

  1. when the user clicks the Login button their entered username and password is sent to a server side script called something like authenticateUser.php

  2. authenticateUser.php validates and sanitises the username and password before inputing them into an sql query to see if they exist in a database table, typically tblusers.

  3. if the query returns 1 record then I set a session variable with a hard to guess key and value -

 
$_SESSION['sessVar'] = 'some hard to guess value';
  1. then at the very top of every page where the user needs to be logged you check for the existence of the session variable in 3) and see if it contains the correct value.
 
<?php
session_start();
 
if(!isset($_SESSION['sessVar']) || 
     $_SESSION['sessVar'] != 'some hard to guess value') {
          die('<h1>You are not an authorised user</h1>')
}
 
//the rest of the code for this page goes below this line
 
 
?>

  1. when the user clicks the Logout button, you take them to logout.php

  2. in logout.php you unset the session variable from 3) and destroy the current session.

 
<?php
session_start();
 
unset($_SESSION['sessVar']);
 
session_destroy();
 
?>

that’s the jist of it.

regarding validating and sanitising username and password user inputs, here are some good examples of how you leave yourself open to sql injection if you don’t.

3

Awesome explanation, Kalon. That explains everything. :slight_smile:

4

Yeah I mean there’s no need to bring database implementation into it if you don’t have to, although remember when using sessions they will become expired upon closing the browser, though a time value is still able to be set.

5

you’re welcome :slight_smile:

when you build your code, if you get stuck just post it and we can try to help.

6

so where do you store the username/password?

7

In a text file completely unencrypted. Gosh.

Heh, in seriousness, his goal was to find out whether a user was already logged in or not, which doesn’t require the use of a database. Though the act of logging the user in does…unless he’s using my fool proof mentioned a few lines up.

8

yep :agree:

but if I just said set a session variable without providing the context of where to set it, it might have been unclear, so I summarised the whole process.

a wise person once said to me

it’s better to under promise and over deliver than to over promise and under deliver.

:slight_smile:

9

Same person who said what’s in the sig? :stuck_out_tongue:

10

no not this time :slight_smile:

the one in the post I recall from my math teacher back in secondary school many years ago now.

11

$_SESSION[‘sessVar’] != ‘some hard to guess value’

Assuming that there are no gaping security holes, what is the difference between:

‘some hard to guess value’

and

‘1’

?

Or in other words, if server side is in complete control of setting session variables, than how does a hard to guess value make any difference?

12

the probability of guessing a 1 character value is much higher than for guessing a 5,10,20,30 or whatever number of characters value.

13

of course, but who cares if the value is guessed? My point is how is a the variable going to be set at all if not directly from the php script? which you have complete control of?

14

Wheeler, is your overall point about security or functionality? Are you saying that the “hard-to-guess” value is arbitrary? I might be wrong here, but it seemed to me that the whole point of the “hard-to-guess” value was an effort to prevent poisoning. Thoughts? (Sorry for the confusion.)

15

my point is about security; if the authentication is determined by a session variable existing or having a certain value, then the difficulty to guess that value seems meaningless to me, based on some assumptions:

  • you are the only person with write access to the source code
  • you would not create any mechanism that would allow the user to determine the key of a session value

Sure there is nothing wrong with having a hard to guess token, I just don’t see what benefit it brings in a normal environment.

The reason being - the session variables are 100% determined by the developer. They don’t exist unless you tell them to.

If I was looking through the source code and saw an encrypted session token I would assume it is going to be used in a cookie or in a form or in some way designed to enhance security.