org.broadleafcommerce.openadmin.server.security.service

Interface RowLevelSecurityProvider

All Known Subinterfaces:

RowLevelSecurityService

All Known Implementing Classes:

AbstractRowLevelSecurityProvider, RowLevelSecurityServiceImpl

public interface RowLevelSecurityProvider

A component that can apply row-level security to the admin

Implementations of this class should extend from the AbstractRowLevelSecurityProvider

Author:

Phillip Verheyden (phillipuniverse)

See Also:

AbstractRowLevelSecurityProvider}, RowLevelSecurityService}

Method Summary

Methods

Modifier and Type	Method and Description
void	addFetchRestrictions(AdminUser currentUser, String ceilingEntity, List<javax.persistence.criteria.Predicate> restrictions, List<javax.persistence.criteria.Order> sorts, javax.persistence.criteria.Root entityRoot, javax.persistence.criteria.CriteriaQuery criteria, javax.persistence.criteria.CriteriaBuilder criteriaBuilder) Used to further restrict a result set in the admin for a particular admin user.
boolean	canRemove(AdminUser currentUser, Entity entity) Hook to determine if the given entity can be deleted by a user.
boolean	canUpdate(AdminUser currentUser, Entity entity) Hook to determine if the given entity can be updated or not.
Class<Serializable>	getFetchRestrictionRoot(AdminUser currentUser, Class<Serializable> ceilingEntity, List<FilterMapping> filterMappings) Contributes to Root determination for addFetchRestrictions(AdminUser, String, List, List, Root, CriteriaQuery, CriteriaBuilder).
GlobalValidationResult	validateRemoveRequest(AdminUser currentUser, Entity entity, PersistencePackage persistencePackage) Validates whether a user has permissions to actually perform the record deletion.
GlobalValidationResult	validateUpdateRequest(AdminUser currentUser, Entity entity, PersistencePackage persistencePackage) Validates whether a user has permissions to actually perform the update.

Method Detail

addFetchRestrictions

void addFetchRestrictions(AdminUser currentUser,
                        String ceilingEntity,
                        List<javax.persistence.criteria.Predicate> restrictions,
                        List<javax.persistence.criteria.Order> sorts,
                        javax.persistence.criteria.Root entityRoot,
                        javax.persistence.criteria.CriteriaQuery criteria,
                        javax.persistence.criteria.CriteriaBuilder criteriaBuilder)

Used to further restrict a result set in the admin for a particular admin user. This can be done by adding additional Predicates to the given list of restrictions. You can also attach additional sorting from the given list of sorts.

You should not attach any of these Predicates to the given criteria, you should instead modify the given lists. These lists will be automatically attached to the criteria after execution.

Existing Predicates and sorts will already be added into the given restrictions and sorts lists.

If you are filtering on a property that exists only in a subclass of an OOB framework entity (like if you extended ProductImpl and you need to add a restriction targeting MyProductImpl) then you need to override getFetchRestrictionRoot(AdminUser, Class, List) to return the class that you are adding criteria to. Otherwise, the entityRoot will be wrong and if you try to get a Path from it then you will run into IllegalArgumentExceptions.

This method is executed prior to any CriteriaTranslatorEventHandler.

Parameters:

currentUser - the currently logged in AdminUser

ceilingEntity - the entity currently being queried from

restrictions - the restrictions that will be applied to the criteria but have not been yet. Additional Predicates to further filter the query should be added to this list

sorts - the sorts that will be applied to the criteria. Additional sorts should be added to this list

entityRoot - the JPA root for ceilingEntity

criteria - the criteria that will be executed. No Predicates or Orders have been applied to this criteria, and nor should they be. All modifications should instead be to the given restrictions and/or sorts

criteriaBuilder - used to create additional Predicates or Orders to add to restrictions and/or sorts

See Also:

#getFetchRestrictionRoot(Class, List)}, CriteriaTranslatorImpl#addRestrictions}

getFetchRestrictionRoot

Class<Serializable> getFetchRestrictionRoot(AdminUser currentUser,
                                          Class<Serializable> ceilingEntity,
                                          List<FilterMapping> filterMappings)

Contributes to Root determination for addFetchRestrictions(AdminUser, String, List, List, Root, CriteriaQuery, CriteriaBuilder). Normally, the query Root is determined in the admin via the given filterMappings. Since row security deals with a CriteriaBuilder directly, if you want to be able to target subclasses then a new Root must be established for that specific subclass.

Note that depending on how you have your filters in the admin frontend (the list grids) set up, you might have to take into account the given filterMappings. The admin will not be able to find a correct root if there is an active filter set on a sibling class that you are attempting to also add more criteria to. For instance, if a class hierarchy exists for A -> B and also A -> C, if there is an active FilterMapping for a property from B and you attempt to add a fetch restriction on a property from C that will not work.

It is acceptable to return null from this method if addFetchRestrictions(AdminUser, String, List, List, Root, CriteriaQuery, CriteriaBuilder) does not rely on any properties from a child class.

Parameters:

ceilingEntity - the entity being queried for

filterMappings - the existing filters passed from the admin frontend

Returns:

the root class that is going to be used for addFetchRestrictions(AdminUser, String, List, List, Root, CriteriaQuery, CriteriaBuilder) or null if no specific root needs to be used

See Also:

CriteriaTranslatorImpl#determineRoot}, FilterMapping#getInheritedFromClass()}

canUpdate

boolean canUpdate(AdminUser currentUser,
                Entity entity)

Hook to determine if the given entity can be updated or not. This is used to drive the form displayed in the admin frontend to remove modifier actions and set the entire EntityForm as readonly.

If the entity cannot be updated, then by default it can also not be removed. You can change this by explicitly overriding canRemove(AdminUser, Entity)

Parameters:

currentUser - the currently logged in AdminUser

entity - the Entity DTO that is attempting to be updated

Returns:

true if the given entity can be updated, false otherwise

See Also:

FormBuilderServiceImpl#setReadOnlyState}

canRemove

boolean canRemove(AdminUser currentUser,
                Entity entity)

Hook to determine if the given entity can be deleted by a user. This is used to drive the DefaultEntityFormActions.DELETE button from appearing on the admin frontend.

You might consider tying the remove to canUpdate(AdminUser, Entity) and explicitly invoking that action yourself.

Parameters:

currentUser - the currently logged in AdminUser

entity -

Returns:

true if the given entity can be deleted, false otherwise

See Also:

FormBuilderServiceImpl#addDeleteActionIfAllowed}

validateUpdateRequest

GlobalValidationResult validateUpdateRequest(AdminUser currentUser,
                                           Entity entity,
                                           PersistencePackage persistencePackage)

Validates whether a user has permissions to actually perform the update. The result of this method is a validation result that indicates if something in the entire entity is in error. The message key from the resulting GlobalValidationResult will be automatically added to the given entity Entity.getGlobalValidationErrors().

If you would like to add individual property errors, you can do that with the given entity by using Entity.addValidationError(String, String). Even if you attach errors to specific properties you should still return an appropriate GlobalValidationResult. In that case however, it might be more suitable to use a PropertyValidator instead.

For convenience, this is usually a simple invocation to #canUpdate(Entity). However, it might be that you want to allow the user to see certain update fields but not allow the user to save certain fields for update.

Parameters:

currentUser - the currently logged in AdminUser

entity - the DTO representation that is attempting to be deleted. Comes from PersistencePackage.getEntity()

persistencePackage - the full persiste

Returns:

a GlobalValidationResult with GlobalValidationResult.isValid() set to denote if the given entity failed row-level security validation or not.

validateRemoveRequest

GlobalValidationResult validateRemoveRequest(AdminUser currentUser,
                                           Entity entity,
                                           PersistencePackage persistencePackage)

Validates whether a user has permissions to actually perform the record deletion. The result of this method is a validation result that indicates if something in the entire entity is in error. The message key from the resulting GlobalValidationResult will be automatically added to the given entity Entity.getGlobalValidationErrors().

If you would like to add individual property errors, you can do that with the given entity by using Entity.addValidationError(String, String). Even if you attach errors to specific properties you should still return an appropriate GlobalValidationResult. In that case however, it might be more suitable to use a PropertyValidator instead.

This is usually a simple invocation to #canDelete(Entity).

Parameters:

currentUser - the currently logged in AdminUser

entity - the DTO representation that is attempting to be deleted. Comes from PersistencePackage.getEntity()

persistencePackage - the full request sent from the frontend through the admin pipeline

Returns:

a GlobalValidationResult with GlobalValidationResult.isValid() set to denote if the given entity failed row-level security validation or not.