Magnolia CORE 5.6.14 is the last maintenance release in the 5.6 branch, which reached end of life on June 25, 2020. This is a bug-fixing and security release that delivers the following:
Stateless protection against login CSRF attack
A stateless technique is now used to protect against any login CSRF attack. See Double Submit Cookie for more information.
When requesting a Magnolia login page before a session is created after authentication, a CSRF token is temporarily kept in a cookie in the client browser. That token is generated with each
GET request before login. When the login form is submitted to the server with a
POST request, the cookie token is matched against the value coming from the request.
To improve security, a salted hash is used for the cookie so that an attacker will not be able to re-create the cookie value from the plain token without knowledge of the server secrets.
MAGNOLIA-7660 (restricted access)
sameSite attribute for
For added security, the
sameSite attribute can be configured for the
JSESSIONID cookie. In Tomcat 8.5.42+, add the following to the
strict value for
sameSiteCookies is now the default in all Tomcat bundles. See Cookie Processor Component for more information.
MGNLTOMCAT-15 (restricted access)
Debug mode for SMTP
Third-party library updates
This release comes with the following third-party library updates to fix some security and compatibility issues:
- H2 database updated to 1.4.200 (MAGNOLIA-7727)
- Hibernate Validator updated to 6.1.4.Final (BLOSSOM-264)
- Log4j updated to 2.13.2 (BUILD-387)
Notable bug fixes
The following issues have been resolved where:
- In the Backup module, Magnolia failed to start upon restore due to incompatibility with H2 1.4.200 (MGNLBACKUP-136).
- In the Cache module,
CacheResponseWrapperdid not retrieve
This issue was previously addressed in PUBLISHING-62. If you no longer experience problems with published node order, you should not upgrade to Publishing 1.0.10.
On the author instance, editors can move nodes to change the order in which they are stored in JCR. Since Magnolia does not track node order history, it is impossible to keep the same order of nodes on the public instance if you publish just one node that has been moved on the author instance. To make sure that the orders of nodes on both instances are aligned, always publish the parent node of any nodes you moved.
- In the Scheduler module, all programmatically added jobs were deleted on restart (MGNLSCH-64).
- In the Synchronization module, synchronizing the same node more than once failed because the target node was locked on the public instance (MGNLSYNC-42).
- In the Task Management module, performance slowed down as more tasks were added. To improve performance, you need to reindex the
tasksworkspace using the new task-specific indexing configuration (TASKMGMT-41).
requestor properties replaced
info.magnolia.task.Task have been deprecated in favor of
Content API classes replaced
PropertyValueDelegateTask classes of the legacy
Content API have been replaced with
See the 5.6.14 changelog for all the changes.
- Backup 2.2.5
- Barebones Tomcat Bundle 1.0.4
- Blossom 3.2.3
- Cache 5.6.4
- Community Edition 5.6.14
- Content Dependencies 1.8.2
- Diff 2.0.1
- Enterprise Edition 5.6.14
- Magnolia 5.6.13
- Mail 5.5.5
- Publishing 1.0.10
- REST Framework 2.1.6
- Scheduler 2.3.4
- Site 1.2.4
- Synchronization 1.8.3
- Task Management 1.2.8
- Third-party library BOM 5.6.10
- UI 5.6.13
The Magnolia team would also like to thank everyone who reported issues, contributed patches or simply commented on issues for this release. Your continued interest helps us make Magnolia better. Special thanks go to Le Bao Duy, Stefan Baur, Tytgat Christian, Philip Mundt and Diana Racho.