A few Shopware 6.4.18.1 quirks

Various smaller issues after updating to Shopware 6.4.18.1 from 6.4.18.0.

385 views
d

By. Jacob

Edited: 2023-03-16 07:57

The last several Shopware updates has been very smooth to install for me, ever since 6.4.11.1 to be exact – but I found a few nasty issues with 6.4.18.1; for one, the administration will automatically log out users after 30 minutes of inactivity, and the value appears to be hardcoded in the login.service.ts file. Ideally I think things like this should be changeable in shopware.yaml, of course with proper warning of potential consequences. Apparently It's not.

The lowest common denominator should not define security practices for everyone else. Imho. Also, it appears there is some sort of Oauth exceptions spamming the log files due to people now getting logged out.

Changing Shopware's session expiration

The precise path for the file you need to change may be like:

/var/www/shopware/vendor/shopware/administration/Resources/app/administration/src/core/service/login.service.ts

If you wish to change the timeout, you need to edit the lastActivityOverThreshold method. Change the threshold from 1500 to 3000 to increase the expiry time to an hour.

Excluded exceptions erroneously logged

In addition to OAuth exception log spam, it appears the shopware.logger.exclude_exception setting in shopware.yaml suddenly stopped working. As I discussed here previously, we can use this setting to exclude certain irrelevant and repetitive exceptions from being logged in our log files. Very important if you want to prevent filling up disk space with redundant HTTP errors or OAuthServerException messages. E.g:

League\OAuth2\Server\Exception\OAuthServerException: "The resource owner or authorization server denied the request."...

Until I figure out why it's no longer possible for us to exclude exceptions in shopware.yaml, I decided to apply a temporary hack(ish) fix to the file:

/var/www/shopware/vendor/league/oauth2-server/src/Exception/OAuthServerException.php

Ca at line 243, in the accessDenied method, you can insert http_response_code(401);exit(); instead of throwing the exception in order to prevent log spam. However, I still managed to discover the following:

  1. shopware.yaml still has the exclude_exception section. This probably means it should work.
  2. The ExcludeExceptionHandler that seem to handle this code IS included when I var_dump the $classLoader variable from index.php.

E.g. This file should handle the excluded exceptions:

/srv/shopware/vendor/shopware/core/Framework/Log/Monolog/ExcludeExceptionHandler.php

However, trying to var_dump the $excludeExceptionList from this file seem to do nothing. Not sure how to check if the variable is actually populated at this point. The good thing is that there is some recent activity in GitHub on this code, so it does not seem the feature has been removed. It's probably just a bug that will be fixed sooner or later.

So far, I have been unable to pinpoint why this happens. I am planning to try pulling from GitHub and perhaps testing a fresh installation of 6.4.18.1 in Docker, but not sure I will get the time, as I will probably have to do this in my own free time.

Links

  1. NEXT-25810: exclude_exception in shopware.yaml not working - Shopware Issuetracker
  2. shopware.logger.exclude_exception - exceptions still being logged - GitHub

Tell us what you think:

  1. Sometimes we may to manually clear cached Shopware files to fix namespace issues.
  2. How to obtain the currently selected API language from Shopware vue components.
  3. How to access file system paths from storefront twig files in Shopware.
  4. How to get or change the currently selected sales channel in an Shopware sw-sales-channel-switch component.
  5. In this tutorial you will learn how to work with Shopware entities in a generic way from PHP, without having to specifically inject the repository in your services.xml file.

More in: Shopware