Issue
-
After upgrading from 7.0 to 7.3, when we start up our bundle for the first time the site does not render any pages (other than to show "powered by" on the home page) and the following error can be observed in the logs:
Caused by: java.lang.RuntimeException: com.liferay.portal.kernel.security.auth.PrincipalException: PermissionChecker not initialized
at com.liferay.portlet.expando.model.impl.ExpandoBridgeImpl.getAttribute(ExpandoBridgeImpl.java:227)
at com.liferay.portlet.expando.model.impl.ExpandoBridgeImpl.getAttributes(ExpandoBridgeImpl.java:292)
at com.liferay.portlet.expando.model.impl.ExpandoBridgeImpl.getAttributes(ExpandoBridgeImpl.java:283)
at com.liferay.sites.kernel.util.Sites.copyExpandoBridgeAttributes(Sites.java:118)
at com.liferay.portlet.sites.util.SitesImpl.applyLayoutPrototype(SitesImpl.java:336)
at com.liferay.sites.kernel.util.SitesUtil.applyLayoutPrototype(SitesUtil.java:89)
at com.liferay.portal.service.impl.LayoutLocalServiceImpl._applyLayoutPrototype(LayoutLocalServiceImpl.java:3706)
... 139 more
Caused by: com.liferay.portal.kernel.security.auth.PrincipalException: PermissionChecker not initialized
...
Environment
- DXP 7.3
Resolution
- This behavior is resolved by installing a patch including the fix for LPS-133177, which is currently scheduled for release within a future fix pack (or can be added via a hotfix).
- Alternately, as a workaround the following portal property can be set prior to the next startup event (only needed for one startup attempt), which will allow the error to be bypassed:
permissions.custom.attribute.write.check.by.default=false
Additional Information
- This error can be observed when a layout is attempting to retrieve an Expando attribute to apply to one of the site's pages, which requires a permissions check for the attribute to be displayed/accessed as expected. However in this case (where it is an automated initial startup process accessing the page for the first time, rather than a user with permissions accessing the page), the necessary permissions to access the expando attribute are not present (as there is no current user for the process). As such, once the error has been bypassed using the workaround above (or by implementing the LPS's fix), the workaround configuration is no longer needed.