How Do PHP Sessions Work? (Not "How Are They Used")

How do PHP sessions work? (not how are they used?)

In the general situation :

the session id is sent to the user when his session is created.
it is stored in a cookie (called, by default, PHPSESSID)
that cookie is sent by the browser to the server with each request
the server (PHP) uses that cookie, containing the session_id, to know which file corresponds to that user.

The data in the sessions files is the content of $_SESSION, serialized (ie, represented as a string -- with a function such as serialize) ; and is un-serialized when the file is loaded by PHP, to populate the $_SESSION array.

Sometimes, the session id is not stored in a cookie, but sent in URLs, too -- but that's quite rare, nowadays.

For more informations, you can take a look at the Session Handling section of the manual, that gives some useful informations.

For instance, there is a page about Passing the Session ID, which explains how the session id is passed from page to page, using a cookie, or in URLs -- and which configuration options affect this.

What do I need to store in the php session when user logged in?

Terminology

User: A visitor.
Client: A particular web-capable software installed on a particular machine.

Understanding Sessions

In order to understand how to make your session secure, you must first understand how sessions work.

Let's see this piece of code:

session_start();

As soon as you call that, PHP will look for a cookie called PHPSESSID (by default). If it is not found, it will create one:

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

If it is found, it takes the value of PHPSESSID and then loads the corresponding session. That value is called a session_id.

That is the only thing the client will know. Whatever you add into the session variable stays on the server, and is never transfered to the client. That variable doesn't change if you change the content of $_SESSION. It always stays the same until you destroy it or it times out. Therefore, it is useless to try to obfuscate the contents of $_SESSION by hashing it or by other means as the client never receives or sends that information.

Then, in the case of a new session, you will set the variables:

$_SESSION['user'] = 'someuser';

The client will never see that information.

The Problem

A security issue may arise when a malicious user steals the session_id of an other user. Without some kind of check, he will then be free to impersonate that user. We need to find a way to uniquely identify the client (not the user).

One strategy (the most effective) involves checking if the IP of the client who started the session is the same as the IP of the person using the session.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    die('Session MAY have been hijacked');
}

The problem with that strategy is that if a client uses a load-balancer, or (on long duration session) the user has a dynamic IP, it will trigger a false alert.

Another strategy involves checking the user-agent of the client:

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}

// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
    die('Session MAY have been hijacked');
}

The downside of that strategy is that if the client upgrades it's browser or installs an addon (some adds to the user-agent), the user-agent string will change and it will trigger a false alert.

Another strategy is to rotate the session_id on each 5 requests. That way, the session_id theoretically doesn't stay long enough to be hijacked.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['count'] = 5;
}

// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
    session_regenerate_id();
    $_SESSION['count'] = 5;
}

You may combine each of these strategies as you wish, but you will also combine the downsides.

Unfortunately, no solution is fool-proof. If your session_id is compromised, you are pretty much done for. The above strategies are just stop-gap measures.

Why sessions are not working in home directory of website

Your robots.txt file has absolutely nothing to do with PHP. It is purely on how to tell ethical robots what files to index.

The usual problem with sessions "not working" in PHP is due to session_start(); not being called.

Please add the following code to the top of pages where they are not functioning:

if (session_status() === PHP_SESSION_NONE) {
    session_start();
}

Honestly? it's been over 11 years since I have typed session_start(). Why? because, if you're coding this naked in PHP in 2021, you're doing something incredibly wrong.

Please, please, learn Laravel or any modern framework. You, your project, your coworkers, the world, will all be better off.

I code PHP daily and I literally haven't messed with $_SESSION[] directly since the probably 2010. It's like doing document.getElementById('foo'); in JavaScript. Please don't do that, either ;-)

P.S. You might consider learning how to design stateless PHP apps, relying on the frontend AJAX to store state, via localStorage.getItem('key'), using JWT Tokens (tymon/jwt-auth) as the authentication system.

That's how we've all been rolling for the last 5 years, actually.

Please read this article:

Goodbye PHP Sessions, Hello JSON Web Tokens

PHP Session Data Not Being Stored

Here are a couple suggestions (I don't really know what's happening and/or why ; so they are only suggestions ; maybe one will solve the problem ^^ ).

First of all, a couple of questions :

(They matter at least if none of these suggestion does the trick)

Which version of PHP / Apache are you using ?
Are you on Windows ? Linux ?
If you are on your "production" server, what hosting service are you using ? Maybe there's something special about it ?
Is the problem present for every one ?
- Is there always a problem when you are browsing the site ?
- Is it still present when you are accessing the site from another browser ?
- What about from another computer ?
If you use something like var_dump($_SESSION); die; at the end of the script that sets data in session, what does it give ?

First idea : what if you set some header to disable caching by the browser ?

Stuff like this, for instance :

session_start();
header("Cache-control: private");

Second idea (at least if you are on windows) : did you try disabling you antivirus / firewall ?

Is the session cookie correctly created in the client's browser ?

If you are using sub-domains (or not) : is the cookie's domain OK ? What about it's expiration date ?

Third idea :

you said error_reporting is set to E_ALL, which is nice
what about display_errors ? Is it set to On so that errors get displayed ?
Is there anything interesting in PHP/Apache's error_log ?

Another one : Are you sure there is absolutly nothing that gets to the output before the session_start ? Not even white spaces ?

Yet another one : Are you sure about permissions on the directories / files ?

Permission to write in a directory means you can create new files, and/or delete old ones.
- But, if I remember correctly, not that you can modify them
To modify files, you need write access on the files too
- Actually, your webserver need write access to those files ^^

What are the permissions on the session's directory, and on the (empty) files that get created ?

I'm beginning to run out of ideas... With a bit of luck, maybe one of those will be the right one... Or help you find out what the right one would be !

Good luck !

Sessions and php redirect doesn't work

Mystery solved here:
Byte Order Mark

Sample Image

Best answer you will find:

https://stackoverflow.com/a/8028987/424004

What are cookies and sessions, and how do they relate to each other?

Let's go through this:

Cookies and sessions are both ways to preserve the application's state between different requests the browser makes. It's thanks to them that, for instance, you don't need to log in every time you request a page on StackOverflow.

Cookies

Cookies are small bits of data, (maximum of 4KB long), which hold data in a key=value pairs:

name=value; name2=value2

These are set either by JavaScript, or via the server using an HTTP header.

Cookies have an expiry datetime set, example using HTTP headers:

Set-Cookie: name2=value2; Expires=Wed, 19 Jun 2021 10:18:14 GMT

Which would cause the browser to set a cookie named name2 with a value of value2, which would expire in about 9 years.

Cookies are considered highly insecure because the user can easily manipulate their content. That's why you should always validate cookie data. Don't assume what you get from a cookie is necessarily what you expect.

Cookies are usually used to preserve login state, where a username and a special hash are sent from the browser, and the server checks them against the database to approve access.

Cookies are also often used in sessions creation.

Sessions

Sessions are slightly different. Each user gets a session ID, which is sent back to the server for validation either by cookie or by GET variable.

Sessions are usually short-lived, which makes them ideal in saving temporary state between applications. Sessions also expire once the user closes the browser.

Sessions are considered more secure than cookies because the variables themselves are kept on the server. Here's how it works:

Server opens a session (sets a cookie via HTTP header)
Server sets a session variable.
Client changes page
Client sends all cookies, along with the session ID from step 1.
Server reads session ID from cookie.
Server matches session ID from a list in a database (or memory etc).
Server finds a match, reads variables which are now available on $_SESSION superglobal.

If PHP does not find a match, it will start a new session, and repeat the steps from 1-7.

You can store sensitive information on a session because it is kept on the server, but be aware that the session ID can still be stolen if the user, let's say, logged in over an insecure WiFi. (An attacker can sniff the cookies, and set it as its own, he won't see the variables themselves, but the server will identify the attacker as the user).

That's the gist of it. You can learn more on the PHP manual on both subjects.

Is Php session data secure?

The session data itself is stored server side. The only thing that is stored on the client's computer is a cookie with a unique identifier so the server knows which session to load at the server side.

Users cannot manipulate the data stored in the session itself, so in that sense, sessions are secure.

Then of course, the cookie itself could be stolen from a user and used by another user (a practice called 'session hijacking'). You can protect your users from this by for example locking a session to their IP-address, browser version, etc and using HTTPS to shield them from people sniffing connections.

How Do PHP Sessions Work? (Not "How Are They Used")