[jwtSession] Moving session cookies to your browser

Hello friends!

Did you wonder how sessions work in MODX? Every time someone visits the site, PHP generates a unique id for it and stores it in a PHPSESSID cookie. At the same time, an modSession record is created in the database with this id and the contents of the current session.

Each time a request is submitted, a cookie with id is sent to the site, and MODX makes a request to the database, loads the session, and then saves the changes to it. At least 2 queries to the database every time.

What does JWT offer us? Abandon all these actions on the server, and give everything you need right away in one token. It can be stored in cookies or in the browser’s local storage. And then, upon request, a user session will be created from it. Accordingly, we throw out work with the database and do not store user sessions on the server at all.

Of course, the question immediately arises — what will happen if the user fakes such a session? JWT standard will not allow it. Tokens can be read, but not changed, because they are all signed by a reliable algorithm with a key on a server that the user does not know. This is a theory, and now we proceed to practice in MODX.

Our favorite system allows you to replace the session handler through the session_handler_class system setting, which I took advantage of by setting my own class. After that, all site scripts that work with $_SESSION read and write in JWT, and not in the database or files. Out of habit, MODX still creates a PHPSESSID cookie, but it is not used in any way.

Unfortunately, it quickly became clear that although cookies do not have a length limit in the RFC, browsers limit them to 4096 bytes. This is very small for work sites that can store a ton of data. Therefore, jwtSession is able to parse one token into several cookies, and then collects them for reading on the server.


It also seemed to me not very cool idea of ​​reading the session data. Is there anything the programmer will save? Therefore, before being issued to the user, its payload is encrypted using openssl_encrypt with the same key used to sign the JWT.
By default, by the way, this is the content of modX::site_id, but you can also specify the system setting jwt_session_secret with an arbitrary phrase.

This is how the decrypted token looks, as you can see, the contents of the session in data are still not available:

And you can't unpack it, if you do not know the secret key.

But, attention, if you have nothing special in the session, then you can disable encryption by setting jwt_session_encrypt, after which you can freely read its contents on the frontend, which is useful for modern javascript sites such as SPA on some VueJS.


The rest of the JWT cookie settings are controlled by the standard MODX settings: session_name, session_lifetime, session_domain and session_path.

As a result, we get a new store for the sessions. Reliable, fast, time-saving, free space and without queries to database. Such sessions are limited only to the settings of the web server, which may not pass large headers.
But here only a hoster can help. There are no such problems at en.modhost.pro, for example.

I do not recommend install jwtSession to production sites right now, it’s better to test it on development sites first and see if it suits you.

Right now it is already working on minishop2.com, you can look there in the cookie.

Updated 25.03.2019

Looks like Safari browser can't handle cookies more than 4 kb in total. So, if you want to support this browser, you need to clearly monitor what is written in the session.