Solr hot update indexing always uses current session user, for example current backoffice user, who triggered solr hot reindex. In lots of real world cases it would lead to wrong results in solr due to different flexible search restrictions, which are applied to backoffice user and solr indexing user.
It is a common case to execute requests to third-party systems on Hybris model change. For that purpose perfectly fits Hybris Interceptors, but execution of long-running operations inside interceptors can lead to great performance degradations and data lost. To deal with that, operations should be executed asynchronously in separate thread.
During migration on newer version of hybris you could find that Backoffice is not working due to failed context initialization with error in creating 'backofficeWarmUpTypeFacadeCaches' bean. Root cause of that issue is broken itemtype definition in composedtypes table.
Modern web development tend to use fronted frameworks with API rest calls to hybris backend. Such approach skips hybris CMS caching system and can lead to performance issues. One of the possible improvement would be to utilize caching on browser side and in such way decrease amount of requests send to server by browser.
SameSite cookie attribute was introduced to improve protection from CSRF attacks by default (read more). 11 August 2020 Chrome changed default behaviour of cookies without SameSite attribute. Starting from that day such cookies would be processed with SameSite=Lax attribute, so cookies would not be sent by default for all third-party POST requests (request made from third-party service to hybris would be also affected).
For example, in case of HOP payment implementation with POST redirect from Payment Provider back to hybris - user will lose his session and see login screen instead of success payment message. Such behaviour encountered due to “JSESSIONID”, “acceleratorSecureGUID” and “storefrontRememberMe” cookies doesn’t specify SameSite attribute.
Test runs and sonarqube analysis for hybris projects are time-consuming and almost in each project it is required to abort CI jenkins job on branch update to reduce load on jenkins servers. Unfortunately there is no commonly used generic solution to solve this task.
In Java 11 was removed support of JAX-WS (JSR 224), and related classes like ant WsImport task, which are highly used in hybris installations for third-party SOAP integrations. For example, cybersource integration extension rely on both wsimport (generates cybersource client from wsdl during ant build) and JAX-WS to execute SOAP requests.
Hybris has possibility to clean up old unnecessary data from a database. OOTB is provided CronJob to remove old CronJobs, but there is nothing to clean up custom item types or even Hybris item types, like business processes and task logs.
Usually it is extremely useful for QA and dev departments to identify build number on environment and verify that required code changes was really deployed. Unfortunately OOTB hybris doesn’t provide any mechanism for that.
Starting from January 15, 2020 maven central repository is not supporting access via http://repo1.maven.org/maven2 due to security reasons. Unfortunately under the hood hybris uses ant-maven-task, which is not maintained since 2011 and has hardcoded link to http version of maven central.