User sessions in the Framework

Description, how the sessions are managed

In a nutshell: The Framework uses PHP sessions if they are available, but does not rely on their using. It automatically creates connection that is technology independent (used both by PHP back-end and Node server). Mobile application never uses PHP session because it does not work with cookies.

• How PHP session works and why it is not used
• Self-managed session
  • How internal persistent session works
  • Session encapsulation – fUserInfo object
  • Why is PHP session still useful for PHP code
  • Using PHP session to simplify operations with private sessions
• Scalability

How PHP session works and why it is not used

Don't worry to skip to the next session if you are familiar with the PHP session management.

PHP manages session linked with session id stored in the user cookies. Cookies are managed almost automatically so that application can start session that is loaded from the storage. For each use PHP stores session in the temporary file. Session is defined by the $_SESSION array of values.

Problem with PHP sessions

PHP sessions works good as long as:

• Back-end is managed only by PHP
• Client cooperates and returns cookie with PHP session ID

When any of the mentioned conditions is not fulfilled, sessions are useless. There are other reasons why not to use them like load balancing but these are more-or-less easily solved by shared cache that stores also the session files.

AyMINE does breaks both conditions and the reasons are general and valid for any similar framework:

• Server is open for several platforms not only PHP but also Node
• Application from the mobile device does not send cookies but only REST requests
• Application could be long-time disconnected when mobile device is out of internet. PHP session is closed after the while and the mobile application loose connection based on the session.

Sessionless? Yes / No

SOA environment loves the stateless components. They are easily manageable and switchable and – in theory – easily scalable.
The scalability is always theoretical. Components works with database and the database should be shared – and the endless scalability is out.
AyMINE modules are stateless … except session. Server modules manages two types of processes:

• Processes started by user are always processed in the user-defined context including right control, user roles and language settings.
• Processes started by the system messaging could be in the client-related context, user-related context or stateless. Events generated by the user-initiated processes have user-related context but the receiver – event processer – decide internally if user-context is disregard, utilised or even required.

Self-managed session

Framework use its own cache and stores session internally in the cached block of data. Session are persistent for a long time, but their identification is regularly changed (floating session ID). Internal session are used independently on the PHP session- PHP sessions are utilized by the PHP part of the server but they are overwritten by the internal session.

How internal persistent session works

PHP session is activated and the internal session is managed in the PHP session. The internal session is stored both in the persistent cache.

When a new REST request comes from a client it shall contain internal session ID. Tasks processed by PHP starts PHP session, however it does not contain almost anything. System loads internally managed persistent session and creates session context – user rights, link to stored files and optionally data stored by modules.

Session encapsulation – fUserInfo object

Persistent session is managed by singleton object fUserInfo. All session-related functionality is available by static methods of this singleton.
Of course, the singleton is session-dependent. Each session has its own session-related context.

Why is PHP session still useful for PHP code

PHP session is used only to support PHP functionality related with sessions. PHP starts user’s session from the persistent session even when PHP session ID is not sent. (As mentioned, it is not sent by mobile application calling REST request.)

All modules could use temporary cache – data structures and loaded information stored in the module-related singletons (typically private static data structures that are active until end of the processes user request). These are under control of the PHP session and don't work correctly when session id not active. That's why the session is active although almost not used to make session-related stable environment.

Using PHP session to simplify operations with private sessions

PHP session are used in the PHP environment to store data about the permanent internal session because reloading PHP session is faster than persistent session. They are used in case that PHP session ID is provided by the client but the PHP session ID must match with the floating session id of the internal session. If they does not match, PHP session is cancelled and new session is created from the internall session.

PHP session stores values:

• $_SESSION['fUserInfo'] – serialised fUserInfo object data (contains all object data). The object is stored to the persistent cache after each change and available to the Node back-end as well.
• $_SESSION['userIntSession'] – floating identification of the internall persistent session. Only ID value, no more information

If session is stored and reloaded by PHP, data from fUserInfo are extracted and immediatelly available. If they are not available, fUserInfo is reloaded from database – from sysClient and sysUser tables. It takes one more database read that is skipped if data from PHP session are available.

Session contains only necessary data for user identification. Each server platform could build up session data according to its needs. PHP needs only data defined by the fUserInfo object:

class fUserInfo
{
   /** Link to the privately stored singletone data  */
   private static fUserInfo $me;
   /** Name and sure name used to store data in reports
    * Depreciated – do not use it in new functions. Candidate to be removed
    */
   public string $userDesc;

   /** User preferred language – used for messages for used */
   public string $lang;

   /** Official client language – used to generate documents and information stored in the system */
   public string $langCode;

   /** Default client currency */
   public string $currency;

   /** user ID */
   public int $sysUserID;

   /** Client ID */
   public int $sysClientID;

   /** Serialised information about last stored file */
   public array $moduleData;

   /** All user roles – loaded by USER when requested
    * Note requested for most common user – webuser
    */ 
   public null|string $allRoles;
   /** List of primary roles used to check rights (minimal set can speed up the selection) */
   public null|string $primRoles;
   ...
}  

If the PHP session is available, it also stores and re-creates other session values:

• $_SESSION['sysUserID'] – user identification
• $_SESSION['sysClientID'] – client identification
• $_SESSION['WEBSession'] – identification of the web session (access of the web client. The session does not track reader; it is single for web portal not for visitor. See more about that web pages managed by the CMS )

Scalability

The scalability depends on the ability to dynamically use any arbitrary computer to handle the session. The framework internally-managed session supports the session transferring via the shared connection id that is not the session id but an internal identification of the client connection. This single string is verifies the user's connectivity. All other values (like used language) is loaded when necessary.