Commits on Jun 12, 2024

1. [IMP] core: add session deletion mechanism …

   Objective:
   ----------
   A user must be able to see which of his sessions/devices are active.
   Make it easy to block devices and analyse current sessions.
   If a user notices unusual operations concerning him on another device,
   he must be able to stop these operations by blocking the session used by this device.
   
   General:
   --------
   A device is uniquely identified by its name, IP address and the session to which it is linked.
   Consequently, a device is always linked to a session, and a session is always linked to at least one device.
   
   A device is tracked with its last activity.
   The same device is updated every X seconds in order to track its use in terms of duration of activity.
   
   Tracking data is collected within the session itself.
   This data is updated in the database when necessary (according to elapsed time) and possible (type of cursor).
   
   Within the database, data are inserted as logs (model `res.device.log`).
   The `res.device` model is responsible for filtering the logs so that the user can obtain usable data.
   Logs are cleaned during garbage collection.
   
   Each user sees data from their own devices.
   Administrators can view all devices.
   
   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 on 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 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 (64^2 instead of 16^2).
   
   Task:3627898

   

   thle-odoo committed Jun 12, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for c385600
   • Browse repository at this point

   Copy the full SHA

   c385600 View commit details

   Browse the repository at this point in the history