Session size of 276672 exceeded allowed session max size of 256000 - but in Magento 2.4.3 backend

[groomershop-mt]

UPDATE: as per discussion, we agreed that is ok to have a low limit for session size to prevent DDOS attacks, value can be changed via the admin panel if needed. Another problem that should be addressed is - suppressed problem, without any error notification to the user and solution for the issue should be provided.

After upgrading to Magento 2.4.3, when we log into backend (admin panel), everypage hangs/is loading about 30 seconds.

In logs we see exceptions: Session size of 276672 exceeded allowed session max size of 256000.

We are ursing Redis for sessions.

Does anybody else have similar issue after upgrading to Magento 2.4.3?

From redis-cli monitor we see that in each second is repeated: 1628681344.757076 [3 127.0.0.1:34310] "hincrby" "sess_1g2sgh25saul85a424puad785d" "lock" "1"

Steps to reproduce (*)

Upgrade Magento 2.4.2-p1 to 2.4.3 Configured Magento to use Redis for session storage Stores -> Configuration -> Advanced -> System -> Security - Max Session Size in Admin and Max Session Size in Storefront set to 100 and Saved Navigate to any page from Admin -

Expected result (*)

It should not break/impact any store functionality

Actual result (*)

Page load time is increased to more than 30 sec

[m2-assistant[bot]]

Hi @groomershop-mt. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

  :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[jorgb90]

Confirmed! Exact same issue here after upgrade to Magento 2.4.3! We are also using Redis for sessions.

[groomershop-mt]

From https://devdocs.magento.com/guides/v2.4/release-notes/backward-incompatible-changes/reference.html We have found that a field/setting e.g. system/security/max_session_size_admin has been added. It's default value is 256000. After increasing it, the problem is solved.

Now the sesssion record is being saved - it has size over 256000. We have check this record and there is a lot of date with privileges settings - we have quite a lot of extensions installed, so there is more privileges, then in clear Magento setup.

[groomershop-mt]

Our suggestion is to increase the default value for system/security/max_session_size_admin to 512000 (or minimalize the the permissions entries in session record). The same problem occur, when we change session storage to files.

[jorgb90]

Yes thats it. Why not set it as "0" to disable it? What can go wrong?

[ghost]

Hello,

Same issue,

I have edit:

/vendor/magento/module-security/etc/config.xml

....

512000 512000

....

[in-session]

Had this morning also the same problem, the value should be set in any case high or to 0

[ghost]

You can also change this in your /app/etc/env.php for avoid lock issues:

'disable_locking' => '0', to 'disable_locking' => '1' in your redis session settings section

[timpea]

Same problem here, when trying to create an order in the admin, could add the 1st product fine, adding any additional products to the order would cause it to hang. @achatpc fix for session size worked perfectly.

[mrtuvn]

Look i got same behavior but still got admin work. But sometimes loaders seem load longer than usual Setup redis session and cache frontend as default. All caches enabled in developer mode

preconditions bin/magento config:set web/secure/offloader_header X-Forwarded-Proto bin/magento config:set web/secure/use_in_frontend 1 bin/magento config:set web/secure/use_in_adminhtml 1 bin/magento config:set web/seo/use_rewrites 1

'session' => [
        'save' => 'redis',
        'redis' => [
            'host' => 'redis',
            'port' => '6379',
            'password' => '',
            'timeout' => '2.5',
            'persistent_identifier' => '',
            'database' => '2',
            'compression_threshold' => '2048',
            'compression_library' => 'gzip',
            'log_level' => '3',
            'max_concurrency' => '20',
            'break_after_frontend' => '5',
            'break_after_adminhtml' => '30',
            'first_lifetime' => '600',
            'bot_first_lifetime' => '60',
            'bot_lifetime' => '7200',
            'disable_locking' => '0',
            'min_lifetime' => '60',
            'max_lifetime' => '2592000',
            'sentinel_master' => '',
            'sentinel_servers' => '',
            'sentinel_connect_retries' => '5',
            'sentinel_verify_master' => '0'
        ]
    ],
   'cache' => [
        'frontend' => [
            'default' => [
                'id_prefix' => '69d_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => 'redis',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                    'compression_lib' => 'gzip',
                    'persistent' => '',
                    'force_standalone' => '0',
                    'connect_retries' => '1',
                    'read_timeout' => '10',
                    'automatic_cleaning_factor' => '0',
                    'compress_tags' => '1',
                    'compress_threshold' => '20480',
                    'preload_keys' => [
                        '69d_EAV_ENTITY_TYPES',
                        '69d_GLOBAL_PLUGIN_LIST',
                        '69d_DB_IS_UP_TO_DATE',
                        '69d_SYSTEM_DEFAULT'
                    ]
                ]
            ],
            'page_cache' => [
                'id_prefix' => '69d_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => 'redis',
                    'database' => '1',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '0',
                    'compression_lib' => ''
                ]
            ]
        ],
        'allow_parallel_generation' => false
    ],

Updated to 2.4.3 then set max_session_size_admin to 1000

Log show [2021-08-12 16:02:54] main.WARNING: Session size of 87533 exceeded allowed session max size of 1000. [] []

Tempor workaround: set config to 0

bin/magento config:set system/security/max_session_size_admin 0 bin/magento config:set system/security/max_session_size_storefront 0

Or config session in app/etc/env.php ['session']['redis']['disable_locking'] = '1'

[mrtuvn]

Look likes updates in this commit https://github.com/magento/magento2/commit/c2a591c4b5e382057260ee2199d133e094762ed8 => Landed to 2.4.3 But not available in 2.4-develop yet

[n2diving-dgx]

Upon upgrading from 2.3.7 to 2.4.3 I was unable to complete an admin login, the MFA would succeed and then loop back to asking for the MFA again. Chased this for hours thinking it was a MFA issue. Simply disabling Two Factor Authentication would allow a successful login and all looked good. The looping on MFA was apparently related to the session limit issue. The default value for 'session limit' was 256000 and needs to be much larger at least for our installation. Increased to 512000, which resolved the issue.

[marvinhinz]

Having the same issue after upgrading to 2.4.3

[mrtuvn]

Yes problem still exist but curiously if we put value to something does magento will got session size go beyond of that ??

[marvinhinz]

@mrtuvn it seems its the write call is only executed when the size is not exceeded yet or the max size is null.

https://github.com/magento/magento2/blob/c2a591c4b5e382057260ee2199d133e094762ed8/lib/internal/Magento/Framework/Session/SaveHandler.php#L130

If the max size is exceeded, the current session data is retrieved and saved again, this seems to create a loop thats constantly locking the session handler. @michaelyu0123 can you maybe explain the idea / intended behaviour behind this?

[michaelyu0123]

@marvinhinz It is as you said, the original intention was just to set the session content to what is already stored. @groomershop-mt, could you please provide the steps to reproduce this issue? Thank you.

[marvinhinz]

@michaelyu0123 wouldnt it be sufficent to just discard the "to-be-saved" data and throw an exception when the limit is reached?

[michaelyu0123]

@marvinhinz, that is something that will be looked into. Thanks.

[aaronsilber]

We are experiencing what look to be very similar symptoms to the bug described here, but on Magento 2.3.7-p1. It looks like the changes to SaveHandler.php are also present in this security-only release.

[pmonosolo]

My issue was showing up as a different error: A technical problem with the server created an error. Try again to continue what you were doing. If the problem persists, try again later.

^^^ this would pop up on every admin page.

The URL that was failing: http://magento.test/admin/mui/index/render/key/479b831574442521ca469efdc376886fde3c57d23eebbaced4a6a7f65a44bf10/?namespace=notification_area&sorting[field]=created_at&sorting[direction]=asc&isAjax=true

^^^ looks like it was some kind of notification area Ajax update. Notification area where "indexers are invalid" shows up was not there so, no data was coming through.

The response to the error was:

UI component could not be rendered because of system exception
error code: "0"

In exception logs, I was getting: [2021-08-13 22:48:42] main.CRITICAL: Unable to unserialize value. {"exception":"[object] (InvalidArgumentException(code: 0): Unable to unserialize value. at /var/www/php/vendor/magento/framework/Serialize/Serializer/Serialize.php:35)"} []

Security session setting to 512000 did not work. Only after I set it to 0 it worked.

UPDATE:

Setting 'disable_locking' => '0', to 'disable_locking' => '1' also worked. I just added the maximum allowed size in env.php - 'max_lifetime' => '2592000'

[DuckThom]

I was running into the same issue on the admin panel on a couple of projects. I noticed that Magento dumps the entire admin user model + relations (namely, all the ACL permissions) into the session, which is a lot of data. Currently our average admin session size seems to be around 543000 without any special modifications to the admin panel. If this is also the case on clean installations (in our case, we're using Commerce) then the default value of 256000 seems to be way too low.

[birdman002]

This issue took me a week to figure out when we got access to it in July (Commerce) finally realizing like DuckThom said it dumps literally all the ACL permissions into the session. Default 256000 seems like a lot but when its all the ACL info then it renders TFA useless as well we can't edit order because of this issue. You can replicate this issue by assigning like 7-9 admin user roles to one person and then try logging into the admin with it. Hoping support can provide a fix for this. This is delaying our upgrade to this version

[hostep]

@nathanjosiah: tagging you in here, you might be interested in this, especially in the last few comments.

[nathanjosiah]

@hostep thanks for the heads up. Looking into this

[WebHostingAce]

I was having the same issue. 2.4.3 admin hangs randomly. I will try the session "Max Session Size in Admin" set to 0. Thank you everyone who involved in this.

[refueledinc]

I'm having the same issue with M2.4.3 and admin taking 30 seconds and Redis showing locking happening.

Any chance you guys have Amasty and Mirasvit extensions? If so, could you share which ones? I've been debugging this issue for over 20 hours and see some oddities in Redis monitor especially with mirasvit.

[birdman002]

@refueledinc we do have amasty extensions, but this issue can be replicated on a vanilla instance of 2.4.3. Take a look at your ACL permissions if you have a lot of user roles that will cause this issue to happen. Magento is storing all the ACL role resources in the session data. I have no tried any of the above solutions of changing the session size

[WebHostingAce]

I'm having the same issue with M2.4.3 and admin taking 30 seconds and Redis showing locking happening.

Any chance you guys have Amasty and Mirasvit extensions? If so, could you share which ones? I've been debugging this issue for over 20 hours and see some oddities in Redis monitor especially with mirasvit.

Amasty Feed Amasty Landing Pages

[refueledinc]

@birdman002 I wasn't able to replicate on vanilla magento despite having 8 roles. However, the issue does happen when I start enabling amasty/mirasvit modules. I do agree it appears to be ACL and session related. For now, increasing the value of "Max Session Size in Admin" fixed the problem for me.

[kovalchukVM]

faced the same issue on Magento commerce v.2.3.7-p1 and Redis used for session, as @marvinhinz wrote above the issue is in write function in file lib/internal/Magento/Framework/Session/SaveHandler.php

    public function write($sessionId, $data)
    {
        $sessionMaxSize = $this->sessionMaxSizeConfig->getSessionMaxSize();
        $sessionSize = strlen($data);

        if ($sessionMaxSize === null || $sessionMaxSize >= $sessionSize) {
            return $this->callSafely('write', $sessionId, $data);
        }

        $this->logger->warning(
            sprintf(
                'Session size of %d exceeded allowed session max size of %d.',
                $sessionSize,
                $sessionMaxSize
            )
        );

        return $this->callSafely('write', $sessionId, $this->read($sessionId));
    }

at the moment when Magento calls write($sessionId, $data) the session is still locked by the previous call of https://github.com/magento/magento2/blob/c2a591c4b5e382057260ee2199d133e094762ed8/lib/internal/Magento/Framework/Session/SaveHandler.php#L100

supposed that lock will be released here https://github.com/magento/magento2/blob/c2a591c4b5e382057260ee2199d133e094762ed8/lib/internal/Magento/Framework/Session/SaveHandler.php#L119 but in case $sessionSize is higher than $sessionMaxSize the session will be read once again https://github.com/magento/magento2/blob/c2a591c4b5e382057260ee2199d133e094762ed8/lib/internal/Magento/Framework/Session/SaveHandler.php#L130 which actually can not be done as it is still locked by the same process in the previous call. Then depending on Redis setting break_after_adminhtml (which is 30 by default) the process gets into the loop and waits that time, then takes the lock to reads session data.

I don't really see any point in reading session data again, as we already have it loaded in $data, also it causes the session to be locked and page load increases to the break_after_adminhtml value in seconds.

I believe the public function write($sessionId, $data) should be like

    public function write($sessionId, $data)
    {
        $sessionMaxSize = $this->sessionMaxSizeConfig->getSessionMaxSize();
        $sessionSize = strlen($data);

        if (null !== $sessionMaxSize && $sessionSize >= $sessionMaxSize) {
            $this->logger->warning(
                sprintf(
                    'Session size of %d exceeded allowed session max size of %d.',
                    $sessionSize,
                    $sessionMaxSize
                )
            );
        }

        return $this->callSafely('write', $sessionId, $data);
    }

[kovalchukVM]

the issue can be simply reproduced even for the frontend:

• go to admin panel Stores -> Configuration -> Advanced -> System -> Security
• set Max Session Size in Storefront to some small number like 100
• clear the case
• visit e.g. /checkout/cart/ page
• it load time is increased ~30 seconds.

I'm pretty sure that Max Session Size was intended to let devs know that session size has increased by adding warning message to logs, and anyway it should not break/impact any store functionality

[m2-assistant[bot]]

Hi @engcom-November. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[emiliatereanu]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @emiliatereanu. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @emiliatereanu, here is your Magento Instance: https://6285bee8f63f9a742019a41ed7f7ae0c-2-4-develop.instances.magento-community.engineering Admin access: https://6285bee8f63f9a742019a41ed7f7ae0c-2-4-develop.instances.magento-community.engineering/admin_3e67 Login: f601a253 Password: fffd30283ecb

[convenient]

Seen on 2.3.7-p1, admin panel is practically unusable

[engcom-November]

Verified the issue after upgrading from 2.4.2-p1 to 2.4.3 and the issue is reproducible with below steps: Configured Magento to use Redis for session storage Stores -> Configuration -> Advanced -> System -> Security - Max Session Size in Admin and Max Session Size in Storefront set to 100 and Saved Navigate to any page from Admin - Issue: Page load time is increased to more than 30 sec

[github-jira-sync-bot]

:white_check_mark: Jira issue https://jira.corp.magento.com/browse/AC-1170 is successfully created for this GitHub issue.

[m2-assistant[bot]]

:white_check_mark: Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[engcom-Lima]

Hi @groomershop-mt,

Session limitation is added in magento to prevent DDoS session attacks with default value of 256kb as per internal discussions. To avoid any inconvenience to users, configuration field has been provided under Stores->configuration->Advanced->System->Security-> 'Max Session Size in Admin' and 'Max Session Size in Storefront'. Request you to make use of these two fields as per your site requirements. Please refer https://docs.magento.com/user-guide/stores/security-session-management.html page for related information.

Closing this ticket as there is no fix required. Please feel free to reopen the ticket if you have any concerns.

Thank you.

[marvinhinz]

@engcom-Lima There is indeed a fix required, its okay not to increase the default limit, but how can you be okay with nearly infinite loading times and no message for the user whatsoever? Just throw an exception when the limit is exceeded.

[mrtuvn]

Lol so basically no any fixes admin only have set value to 0 for bypass to disable in order re-access or set value to very big int to avoid exceed and infinity loading.

[t-heuser]

@ihor-sviziev Can you please reopen this ticket. It's still an issue and the solution provided is not convinent. We're experiencing the issue after adding multiple user roles (acl). Then every user which has specific rights cannot login to the adminhtml anymore or its very slow. Admin users with full rights can still login easily.

Confirmed on magento 2.4.3-p1.

[ihor-sviziev]

The issue is still not resolved.

On Magento 2.3.7-p2, the admin user mode is getting saved into the session. That significantly increases the size of the session. Custom extensions also write some data to the session, even when no data is stored.

I think we should re-open this issue for further investigation. /CC @sidolov @kandy

[github-jira-sync-bot]

:x: Cannot export the issue. This GitHub issue is already linked to Jira issue(s): https://jira.corp.magento.com/browse/AC-1170

[ihor-sviziev]

@sidolov @sdzhepa @sivaschenko , could you check why the issue can't be exported to Jira after re-opening the Github case?

[sidolov]

@ihor-sviziev because the issue already exists, it was re-opened.

[engcom-Hotel]

Hello @groomershop-mt,

As per the expert advice, limiting max session size was introduced as a DDOS measure and the session size can be increased via the admin panel. I don't think any change is required for this ticket.

Hence we are closing the issue.

Thanks

[t-heuser]

@engcom-Hotel Why? @ihor-sviziev reopened the ticket 13 days ago and stated that the issue is not resolved. So please reopen this ticket and leave it open until a real solution is provided. This ticket is getting ridiculous.

[marvinhinz]

@engcom-Hotel please read the issue comments again carefully. The problem is not resolved. The session limit is okay, but its not okay to have an unresponsive application without appropriate error message when the limit is exceeded.