Currently, on login, myrunes creates a unique base64 session key which is, on the one side, stored as _session cookie in the authenticated users brwoser, as same as, on the other side, in the database on the server in combination with the users ID.
After login, on each following request, the browser sends the cookie with the request and the server checks the colelcted session key against the database entry. If they match, the request is authorized.
Future State (>= 1.7.0)
On login, the server will generate a JWT (Json Web Token), which is a base64 encoded piece of JSON data which is hash signed alongside with a 128bit key stored on the server to validate the authenticity of the JWT. The JWT also contains the time of issue and expiration to validate the session. This token will be, as same as a session key, stored as jwt_token cookie in the users browser.
Because everything important like user ID and expiration date is stored in the JWT, sessions are no more required to be stored on the server side. This has both advantages and disadvantages. On the positive site, it removes a lot of complexity to collect and check the session key against the database (or a cached value). Also, JWTs are way more secure because they are cryptographically signed by the server. On the down site, the myrunes server is no more able to track and manage sessions. But this trade-off is acceptable, in my opinion, against the advantages. Even tho an extra layer of session management can be added to the JWT system, of course, but it would counter the advantage of not having to check sessions against the database.
Current State (<= 1.6.0)
Currently, on login, myrunes creates a unique base64 session key which is, on the one side, stored as
_session
cookie in the authenticated users brwoser, as same as, on the other side, in the database on the server in combination with the users ID. After login, on each following request, the browser sends the cookie with the request and the server checks the colelcted session key against the database entry. If they match, the request is authorized.Future State (>= 1.7.0)
On login, the server will generate a JWT (Json Web Token), which is a base64 encoded piece of JSON data which is hash signed alongside with a 128bit key stored on the server to validate the authenticity of the JWT. The JWT also contains the time of issue and expiration to validate the session. This token will be, as same as a session key, stored as
jwt_token
cookie in the users browser. Because everything important like user ID and expiration date is stored in the JWT, sessions are no more required to be stored on the server side. This has both advantages and disadvantages. On the positive site, it removes a lot of complexity to collect and check the session key against the database (or a cached value). Also, JWTs are way more secure because they are cryptographically signed by the server. On the down site, the myrunes server is no more able to track and manage sessions. But this trade-off is acceptable, in my opinion, against the advantages. Even tho an extra layer of session management can be added to the JWT system, of course, but it would counter the advantage of not having to check sessions against the database.