Bitrix Framework

Bitrix24 allows handling sessions as follows:

Session storage in memcached

You need to set the following constants to enable session storage in memcached in the old core/kernel's file /bitrix/php_interface/dbconn.php:

define('BX_SECURITY_SESSION_MEMCACHE_HOST', 'localhost');
define('BX_SECURITY_SESSION_MEMCACHE_PORT', 11211);

Or when using unix-socket:

define('BX_SECURITY_SESSION_MEMCACHE_HOST', 'unix:///path/to/memcached.sock');
define('BX_SECURITY_SESSION_MEMCACHE_PORT', 0);

Then, enable session storage in the database in the proactive protection module. As a result, we get kernel-enabled session storage in memcached.

This method of session storage provides the following advantages:

• no need to track the number of old sessions on the highly-loaded project;
• option to individuate sessions between servers in cluster;
• option to use session that's not waiting for blocking;
• option to use virtual sessions.

Session storage in the database has the same advantages as the session storage in memcached. However, database storage is significantly slower. That's why we recommend using memcached for this purpose instead of database.

Non-blocking sessions

One of issues encountered in large-scale projects with multiple ajax queries is the frequently blocked hits of a single user for standby of blocked session. This is especially applicable for Bitrix24 On premise, where in many locations, files attached to entities are passed to user, after checking access permissions for PHP. That's why, a sort of "sequence" can be built due to standby for blocked session. You can enable a non-blocking session by specifying the constant,before connecting the kernel:

define('BX_SECURITY_SESSION_READONLY', true);

After this action, the session is read from memcached or database without waiting for blocking. For example, this feature is used when passing files.

Virtual sessions

Non-blocking sessions are sufficient for majority of cases. However, in some cases, when we do not need the session altogether, its overly excessive to use a non-blocking session - due to an extra session being created if unavailable. As the result, a large of "trash" sessions are created in case of large amount of unassociated hits. Example of such hits are REST hits.

Virtual session was added to resolve this issue. It works as follows: a session is created in the memory, doesn't wait for blockings and is not saved. To enable it, set the constant, before connecting the kernel .

define('BX_SECURITY_SESSION_VIRTUAL', true);

Please remember that this session type is not saved anywhere. It is used when processing REST queries.