Setting Variables

Hi All,

I’m relatively new to OOP and trying to make headway but am getting a little stuck at the theory, and whether it is how my class is split up,or just a concept I’m not grasping. When dealing with users and their sessions, I have a private variable to contain the user’s ID and is returned by a function. Setting it is where I have a problem - it would obviously be set when a user completes a login successfully - along with other information about them stuck in the database - however when checking if they were logged in, when they have navigated away, and a new instance of the class is called - surely it would need to be set again by the function checking their login - therefore being set in two places. This seems a little bit redundant to me - or am I heading down the right path?


This is the ideal place to use the PHP session. You can read all about PHP sessions here.

Upon successful login, I would set the session variables something like this:
$_SESSION[‘login’] = array();
$_SESSION[‘login’][‘userid’] = $_POST[‘userid’];
$_SESSION[‘login’][‘timestamp’] = time();

Then to check for a valid login on a subsequent page load:

if (array_key_exists('login', $_SESSION)) {
if (array_key_exists('timestamp', $_SESSION['login'])) {
if (time() - $_SESSION['login']['timestamp'] < 900) {
// login is valid, update the timestamp
$_SESSION['login']['timestamp'] = time();
$loginIsValid = true;
} else $error = 'Login timed out';
} else $error = 'Not logged in';
} else $error = 'Not logged in';

The vile art of thread necromancy in action!! And in a two-for-one, the answer given doesn’t really answer the OP’s question. :nono:

First, some background.

HTTP is a stateless protocol. This means that each transaction between server and browser is independent of the others. While this aids the robustness of the web as a whole, it’s a hindrance when dealing with dynamic pages that must carry a state between transactions, such as a logged in state. To do this PHP implements a session variable as the second poster pointed out. You can store the user information there between page loads to recover any information the user provided in a previous transaction.

In an OOP environment the user object is often serialized and then written to the session variable. When the object is unserialized it can recover the information that was serialized for it and return to the state it had before the last page transaction ended.

The best way to serialize an object is to implement the [fphp=serializable]Serializeable interface[/fphp] in that object.

A final note about PHP Sessions - these are mapped to the given server the script executes on. In larger site setups with multiple servers and a load balancer a custom solution may become necessary since the session information on one server may not be easily shared with a second (though there are workarounds).

Now second - the original poster is unlikely to see this reply or the one above since the post was made 2 years ago. Also, I’m fairly certain that their programming skills have grown in the interim. This is the main reason for the site stricture on resurrecting threads, which is jokingly called “thread necromancy,” particularly on RPG boards. It’s better to start a new thread.

Mr. Morris apparently doesn’t care for new guys answering questions. I’ll quietly slink back under my rock …

I don’t see anything out of the ordinary, you did reply to a 2 year old question and Michael offered quite good solution on top of yours.

I’m no diplomat, so I can come off as rude at times. That’s not my intent, just my nature. To clarify - Answering questions isn’t bad - answering old ones is. Any thread more than a month old should not be replied to without good reason. And this one seems to have run its course so I’m putting in a request for its closure.