Objective:
----------
A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual operations concerning him/her on another device, he must be able to stop these operations by blocking the session used by this device. From a technical point of view, a user must be able to block a session linked to an identified device.

General:
--------
- A device is identified by a static part, the device's fingerprint.
- A device is tracked dynamically via its IP address and the timestamp representing its last activity.
- A fingerprint is always linked to one and only one session.
- A session is linked to at least one device.

If a device's fingerprint is modified (for example by a browser update), it will have a new device linked to the session. Consequently, fingerprint tracking does not automatically prevent session theft.

If we find an existing fingerprint for a session, we update its dynamic tracking (IP address and last connection). If a device is suspicious (via its static signature and/or dynamic tracking), it is possible to block the session linked to this device. This has the effect of blocking all devices linked to this session, including the current device if it is part of one. The obligation to block the current device, because another device with malicious intent can spoof the fingerprint (and there's no way to differentiate them).

Fingerprint:
------------
The purpose of a fingerprint is to identify a device. We use the information collected in the request headers. A `raw_fingerprint` is constructed which is a dictionary in JSON format which respects a specific order (to avoid having two different fingerprints for the same device because of the order of the elements). This `raw_fingerprint` will need to be parsed for easy reading.

Note: fingerprint parsing cannot be 100% reliable, but general rules/patterns can be used to gather the relevant information and avoid errors. Example: "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" is a Linux OS with a Chrome browser even if "Mozilla" and "Safari" are two words in the header.

Note supp: rules and patterns of the fingerprint parser can (must) be improved in the future.

Blocking sessions:
------------------
Blocking a session by selecting a device must block the session directly. From an administrator's point of view, if we want to block a session, we expect the session file to be deleted directly from the filesystem. If the session file is no longer present on the filesystem, we can be sure that there is no longer any risk of session usurpation.

Note:
There are several ways of blocking the session, but this is the safest. Blocking a session based on DB field values does not cover scenarios in which we perform a backup, for example.

Find the session file:
----------------------
To find a session file on the filesystem, we need to know the sid of the session (as this is its filename). We don't want to store the sid in the database.
However, we can store a part of it with:
- a large enough part to be certain of the uniqueness of the session;
- a small enough part that we cannot brute force the end of the sid.

Browsing the filesystem has a certain performance cost (and can therefore have defects if abused).

The proposed solution is to change the granularity of the way we store the session on the filesystem. This means finding a compromise between sub-folders and files per sub-folder to browse for a session file.

The sid will be Base64 encoded in order to increase the number of sub-folders and we will have two levels of sub-folders.

Note:
Encoding the sid in Base64 also extends its length.

Update dynamic tracking of devices:
-----------------------------------
Updating devices (including creation) take place at the same time as the session refresh in the filesystem. This is done when we are in the `/web` or `/my` route.

Delete devices:
---------------
We can delete a device at the same time as the linked session is deleted on the filesystem.

Task:3627898

Objective:
----------
A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual operations concerning him/her on another device, he must be able to stop these operations by blocking the session used by this device. From a technical point of view, a user must be able to block a session linked to an identified device.

General:
--------
- A device is identified by a static part, the device's fingerprint.
- A device is tracked dynamically via its IP address and the timestamp representing its last activity.
- A fingerprint is always linked to one and only one session.
- A session is linked to at least one device.

If a device's fingerprint is modified (for example by a browser update), it will have a new device linked to the session. Consequently, fingerprint tracking does not automatically prevent session theft.

If we find an existing fingerprint for a session, we update its dynamic tracking (IP address and last connection). If a device is suspicious (via its static signature and/or dynamic tracking), it is possible to block the session linked to this device. This has the effect of blocking all devices linked to this session, including the current device if it is part of one. The obligation to block the current device, because another device with malicious intent can spoof our fingerprint (and there's no way to differentiate them).

Fingerprint:
------------
The purpose of a fingerprint is to identify a device. We use the information collected in the request headers. A `raw_fingerprint` is constructed which is a dictionary in JSON format which respects a specific order (to avoid having two different fingerprints for the same device because of the order of the elements). This `raw_fingerprint` will need to be parsed for easy reading.

Note: fingerprint parsing cannot be 100% reliable, but general rules/patterns can be used to gather the relevant information and avoid errors. Example: "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" is a Linux OS with a Chrome browser even if "Mozilla" and "Safari" are two words in the header.

Note supp: rules and patterns of the fingerprint parser can (must) be improved in the future.

Blocking sessions lazily:
-------------------------
Blocking a session by selecting a device must not browse the filesystem to find the session file and delete it. Blocking a session must ensure that the next request linked to this session is blocked.

An invalid session is detected if its access token (in the filesystem) is not the one calculated by the server (see `_compute_session_token` method). Note: The result of this calculation is cached (LRU) and it is therefore necessary to clear the cache when it needs to be recalculated.

The result is that if, for a given session, the key used to calculate its HMAC is changed, the session will be automatically invalidated by the current session mechanism.

We therefore need a boolean key (which is True by default) that detects whether at least one device has been blocked for the current session. If this is the case, the session must be invalidated.

SID ---> KEY X + KEY device (`True` according to all devices linked to SID) ---> HMAC A

SID ---> KEY X + KEY device (`False` according to all devices linked to SID) ---> HMAC B >< HMAC A ---> invalid session

The boolean value is stocked in a field that tells whether the devices are active or not.

It is therefore necessary to be able to find all the devices linked to a SID. Using the SID's sha256 directly makes it easy to link a device to an SID without any security problems. This ensures we have a perfect match in the device - SID relationship.

Update dynamic tracking of devices:
-----------------------------------
Device updates (including creation) take place at the same time as the session refresh in the filesystem. This is done when we are in the `/web` route.

Delete devices:
---------------
We can delete a device at the same time as a session is deleted on the filesystem. If a session no longer exists on the filesystem, it is impossible to usurp it, so devices linked to this session no longer need to be tracked. With the session's sha256, we can find all devices we need to delete.

opw-3627898