You are browsing the unmaintained documentation for old Nette 2.2. See documentation for current Nette.


HTTP is a stateless protocol, but almost every application needs to store states between requests, e.g. content of a shopping cart. And exactly for that, the session (or relation) is. We will show you,

  • how to use sessions
  • how to avoid naming conflicts
  • set expiration
  • secure against vulnerability

When using sessions, each user who visits a web page receives a unique identifier called Session ID, which is passed by cookies. It serves as a key for session data. Unlike cookies, which are stored at the browser side, session data are stored at the server side.

The session is managed by the Nette\Http\Session object, which you get by passing it using dependency injection. In presenters simply call $session = $this->getSession().


In pure PHP is session data storage implemented as an array, which is accessible via global variable $_SESSION. The problem is, that applications are usually composed of several independent parts and if every part can use the same array, you'll have to solve naming conflicts sooner or later.

Nette Framework solves this problem by the division of the session space into sections (objects Nette\Http\SessionSection). So then every part of a program uses its own section with a unique name and no collision can occur.

Let's start with a session manager, which is an object of class Nette\Http\Session. We can access this service directly from presenter:

// $this stands for presenter
$session = $this->getSession();
$mySection = $this->getSession('mySection');

Or we can require it using dependency injection, in our case in constructor:

use Nette;

class MyService
	/** @var Nette\Http\Session */
	private $session;

	/** @var Nette\Http\SessionSection */
	private $sessionSection;

	public function __construct(Nette\Http\Session $session)
		$this->session = $session;

		// get section by identifier 'mySection':
		$this->sessionSection = $session->getSection('mySection');

We can use a method hasSection('myCounter') for checking an existence of a section.

There is no need to start or close that session, it's done automatically by framework itself. But we can start it manually by calling $session->start(). If we call that start() method more times, nothing happens and it will have no effect. You can also modify this behaviour in configuration.

And then it's really simple to work with that section:

// variable writing
$section->userName = 'franta'; // or $section['userName'] = 'franta';

// variable reading
echo $section->userName; // or echo $section['userName'];

// variable cancellation
unset($section->userName);  // unset($section['userName']);

It's possible to use foreach cycle to obtain all variables from section:

foreach ($section as $key => $val) {
	echo "$key = $val";

Example: Visit Counter

We will start with an example of a visit counter, which shows how many times did user display a page.

$section = $session->getSection('myCounter');
$section->count++; // increment counter by one
echo "You displayed this page $section->count ×";

Accessing a non-existent variable generates no error (variable has a NULL value). It could be undesirable behavior in some cases and that's why there is a possibility to change it:

$section->warnOnUndefined = TRUE;

How to Set Expiration

Very useful feature is the possibility to set its own expiration time for every section or variable. So we can let expire user's login, but still remember a content of a shopping cart.

// section will expire after 2 minutes
$section->setExpiration('2 minutes');

// variable $section->a will expire after 10 seconds
$section->setExpiration(10, 'a');

Besides a relative time in seconds one can use a UNIX timestamp or a textual form. Interesting is a value of 0, which sets an expiration time to the moment when the user closes his browser:

// variable $section->password will expire when a user closes a browser
$section->setExpiration(0, 'password');

Remember that the expiration time of a whole session (see Session configuration) has to be the same or greater than the time which was set for the separate sections or variables.

Cancellation of a previously set expiration can be achieved by calling removeExpiration() method. Immediate cancellation of the whole section is handled by the remove() method.

Session Configuration

Configuration of a session must be done before using it. The best place to do it is a config.neon.

What to configure? The expiration time. If this setting is not done, every session variable will expire in a moment when a browser window is closed. Storing session after window closing is useful for example for a long user login.

		expiration: 14 days

You can also configure session auto starting.

		autoStart: true # 'smart' is default value

autoStart: smart is recommended. It automatically starts the session only if it already exists.

If you're using a shared hosting, it's suitable to use a custom directory for storing files with session relations:

		savePath: "%tempDir%/sessions"

In this case, %tempDir% will be replaced by value you set in $configurator->setTempDirectory() in bootstrap.php.

If you want to extend the validity of a session (or authentication) for subdomains, let's set just another cookie parameters:

// sets cookie validity for all subdomains
$session->setCookieParameters('/', '');
		cookiePath: '/'
		cookieDomain: ''

Safety First

The server assumes that it communicates with the same user as long as requests contain the same Session ID. The task of security mechanisms is to ensure that this behavior really works and that there is no possibility to substitute or steal an identifier.

That's why Nette Framework properly configures PHP directives to transfer Session ID only in cookies, to avoid access from JavaScript and to ignore the identifiers in the URL. Moreover in critical moments, such as user login, it generates a new Session ID.

Function ini_set is used for configuring PHP, but unfortunately, its use is prohibited at some web hosting services. If it's your case, try to ask your hosting provider to allow this function for you, or at least to configure his server properly.

Known Limitations

In browser Chrome in the “System” section Continue running background apps when Google Chrome is closed., this option is default enable. It causes the cookie that has a set expiration to close the browser, the cookie still lives. Section with expiration 0, when you close the browser is not removed.

Related blog posts