Documentation Home
Changelog

FAQ - General

This section contains Frequently Asked Questions via the support channel that could apply to any installation of Broadleaf.

Why is the Admin displaying a 403 Forbidden error when I try to view a section and/or an entity form?

What is happening is that the system is checking the permissions (which are tied to domain classes) available on the user. The admin user does not have the correct permissions.

This can be due to not having the permission on the class that the admin user wants to view or it could be due to a relationship from the main class to another class.

  1. Check the logs. There is warn level log that should output the class that is causing the issue on the AdminSecurityServiceRemote class. For example:
[ WARN] 13:14:51 AdminSecurityServiceRemote [admin][][] - Detected security request for an unregistered ceiling entity (com.broadleafcommerce.theme.domain.page.PageType). As a result, the request failed. Please make sure to configure security for any ceiling entities referenced via the admin. This is usually accomplished by adding records in the BLC_ADMIN_PERMISSION_ENTITY table. Note, depending on how the entity in question is used, you may need to add to BLC_ADMIN_PERMISSION, BLC_ADMIN_ROLE_PERMISSION_XREF and BLC_ADMIN_SEC_PERM_XREF.

If you do not have the logs enabled for this class, you can turn them on for the org.broadleafcommerce.openadmin.server.security.remote.AdminSecurityServiceRemote class.

  1. Set a breakpoint in the AdminSecurityServiceRemote.securityCheck(...) method, on the following block of code:
for (String ceilingEntityFullyQualifiedName : ceilingNames) {
    isQualified = securityService.isUserQualifiedForOperationOnCeilingEntity(persistentAdminUser, permissionType, ceilingEntityFullyQualifiedName);
    if (!isQualified){
        if (primaryException == null) {
            primaryException = new SecurityServiceException("Security Check Failed for entity operation: " + operationType.toString() + " (" + ceilingEntityFullyQualifiedName + ")");
        }
    } else {
        break;
    }
}

At this point you can inspect the ceilingEntityFullyQualifiedName variable to see which one(s) is(are) causing the issue.

Once you know what class is missing, you will need to add it to the permissions table and attach it to a role or admin user.

When using enterprise, how can I plug into the event system after a product gets promoted and/or approved?

Whenever there is a save to a product or order, a list of cache invalidation producers are called. The Broadleaf framework has two events that get registered. One for sandbox updates, SolrSandBoxProductChangeProducer (this is meant to allow searching while previewing on site) and one for approvals/deployments, SolrProductInvalidationProducer. These create events that are then consumed by the SolrDocInvalidationEventConsumer to do the necessary reindexing.

Let's say that you want to plug into this event system in order to invalidate Solr documents attached to categories. While the logic to actually do the document invalidation is beyond the scope of this article, you can setup the event system that would trigger said logic with the following approach.

In this case, you'd want to create your own MySolrCategoryInvalidationProducer and MySolrCategoryInvalidationConsumer. You would setup the Producer in the same way the BLC producer is setup by first defining the bean then adding it to the list. In doing so it will trigger when a deployment happens. 

<bean id="mySolrCategoryInvalidationProducer" class="path.to.producer.MySolrCategoryInvalidationProducer" />

<bean id="myAdditionalCacheInvalidationProducers" class="org.springframework.beans.factory.config.ListFactoryBean">
    <property name="sourceList">
        <list>
            <ref bean="mySolrCategoryInvalidationProducer" />
        </list>
    </property>
</bean>

<bean class="org.broadleafcommerce.common.extensibility.context.merge.LateStageMergeBeanPostProcessor">
    <property name="collectionRef" value="myAdditionalCacheInvalidationProducers" />
    <property name="targetRef" value="blAdditionalCacheInvalidationProducers" />
</bean>

At this point you can then create the consumer to do whatever it needs so it can appropriately index/reindex Solr.