PHP Class Scope

Question

I am fairly new to PHP. What is the best way to control access to a class throughout a PHP application and where is the best place to store these classes that will need to be accessed throughout the entire application? Example; I have a user class that is created on during the login process, but each time the page post it appears that the object is reinitialized.

I have tried to set property IsLoggedIn and then check that variable each time before creating the object as new again, but this doesn't seem work. I have also tried to use the isSet function in PHP to see if the class variable already exists

Answer 1

This kind of data is going to have to be stored in a session, the only thing that is carried from page to page is Session data (sessions/cookies/...) so your class initialization is not carried over.

You can add information like the users username to the session with:

$username //username from db
$name //name from db
$_SESSION['username'] = $username;
$_SESSION['name'] = $name;

or if you just want to have easy access to all the information about the user you can do:

$_SESSION['user'] = mysql_fetch_assoc($result); //where $result is the response from the db to your login query

after you do this $_SESSION['user'] will be an array with all the details you selected from the database.

Answer 2

You're right, the state of your application is not carried over from request to request.

Contrarily to desktop applications, web applications won't stay initialized because to the server, every time it can be a another visitor, wanting something completely different. You know who's using the desktop application, but you don't necessarily know who's requesting the page. Imagine 10 users doing different thing simultaneously on your web application? You wouldn't keep the whole application running necessarily for each of those visitors. Imagine with 10,000 visitors...

There are ways to keep some data from request to request though. The application will be reinitialized each time, yes, but you can then reload the state of what you were doing. It always revolve around around the same general methods:

1. Cookies; Cookies are a small file that is kept on the client side and which content will be available on each request to you. You could serialize In PHP this is available using $_COOKIE variable. In all cases, you could serialize your classes instances and reload them afterwards. The problem is, you wouldn't want to put sensitive data there as any(malicious)body can see and modify it.

2. POST or GET; In each request, you pass a state in the $_GET request (the URL such as http://localhost/myscript.php?iamatstep=4. Or via a $_POST such as using a hidden input field in a form. This data could be encrypted and make sense only to you, but still, you are putting sensitive data back to the client and anybody could fiddle with it.

3. Database, Disk; Or anything else on the server. Again, you serialize your data in a file for example at the end of a request ready to be used again for the next request. The main advantage is that it stays on your server. The downside is that at this point, you don't know which data to extract back for which request as there might be multiple users on your application at the same time...

And this is where the notion of $_SESSION comes into play. It's just a packaged way of using all of this at the same time. It's not magical as often it's perceived by beginners. When you use a session, the data put into the $_SESSION is stored somewhere on the server (normally a file in a temporary directory although it can be changed to something else like a database) and a unique ID is attributed to this session and passed in a cookie that will follow the visitor from request to request. So the only thing on the client's side is a big number in the cookie. On the next request, the browser tells PHP on the server that it's session number 12345, loads the corresponding file if it exists and then the data is available to you again. If cookies are not enabled, it could be passed in a GET or POST, although it's often better not to go there (see session.use_trans_sid's note).

It often looks like that on each of your pages you need authentication.

<?php

// verify if we have a current session
if (isset($_SESSION['login'])) {
  // get data in current session
  $username = $_SESSION['login']['username'];
  $isLoggedIn = $_SESSION['login']['isLoggedIn'];
} else {
  $username = '';
  $isLoggedIn = false;
}

// take care of the unauthorized users
if (!$isLoggedIn) {
  // maybe a redirection here...
}

// do the things a logged in users has the permission to do

And to set the session, it'll probably look like that:

<?php

// handle the form post of your login page for example
if (isset($_POST['username]) && isset($_POST['password'])) {
  $username = $_POST['username'];
  $password = $_POST['password'];
  // verify the username and password against a database
  if ($everythingIsOkay) {
    // we can consider this user logged in and create a session
    $_SESSION['login']['username'] = $username;
    $_SESSION['login']['isLoggedIn'] = true;
    // and now maybe redirect the user to the correct page
  }
}
// raise an error about an invalid login

And finally, maybe a logout.php page that would do something like that:

<?php

unset($_SESSION['login']);
// redirect the user to the login page