Class DefaultVendorAwareCacheKeyEnhancer
java.lang.Object
com.broadleafcommerce.data.tracking.core.cache.marketplace.vendor.DefaultVendorAwareCacheKeyEnhancer
- All Implemented Interfaces:
VendorAwareCacheKeyEnhancer
- Direct Known Subclasses:
CatalogVendorAwareCacheKeyEnhancer
public class DefaultVendorAwareCacheKeyEnhancer
extends Object
implements VendorAwareCacheKeyEnhancer
Default implementation of
VendorAwareCacheKeyEnhancer
.- See Also:
-
Constructor Summary
ConstructorDescriptionDefaultVendorAwareCacheKeyEnhancer
(VendorAwareTrackablePolicyUtils vendorAwareTrackablePolicyUtils) -
Method Summary
Modifier and TypeMethodDescriptionprotected void
addPropertiesToCacheKey
(Set<String> currentRequiredPolicyRoots, AuthenticationVendorPrivilegesSummary vendorPrivilegesSummary, com.fasterxml.jackson.databind.node.ObjectNode cacheKey) protected boolean
containsAuthorityRoot
(Set<String> permissionRootsToCheck, String authority) void
enhanceCacheKeyWithVendorConsiderations
(com.fasterxml.jackson.databind.node.ObjectNode cacheKey, ContextInfo contextInfo) Typically, implementations of this method should load the current policy requirements and leverageVendorAwareTrackablePolicyUtils
to determine relevant restrictions/restricted-privileges available to the current authentication, and add those details to the provided cache key node.protected PolicyInformation
getPermissionRoots
(PolicyInformation policyInformation) protected VendorAwareTrackablePolicyUtils
getVendorRefsByRelevantRestrictedAuthority
(Set<String> currentRequiredPolicyRoots, AuthenticationVendorPrivilegesSummary vendorPrivilegesSummary) Caching will pretty much only ever be used on read operations, but we can't just filter to vendor restrictions matching the current policy requirements since theContextStateBuilder
's mutability check to setContextState.getMutable()
will perform policy validation against _updates_ as well.
-
Constructor Details
-
DefaultVendorAwareCacheKeyEnhancer
public DefaultVendorAwareCacheKeyEnhancer(VendorAwareTrackablePolicyUtils vendorAwareTrackablePolicyUtils)
-
-
Method Details
-
enhanceCacheKeyWithVendorConsiderations
public void enhanceCacheKeyWithVendorConsiderations(com.fasterxml.jackson.databind.node.ObjectNode cacheKey, ContextInfo contextInfo) Description copied from interface:VendorAwareCacheKeyEnhancer
Typically, implementations of this method should load the current policy requirements and leverageVendorAwareTrackablePolicyUtils
to determine relevant restrictions/restricted-privileges available to the current authentication, and add those details to the provided cache key node.- Specified by:
enhanceCacheKeyWithVendorConsiderations
in interfaceVendorAwareCacheKeyEnhancer
- Parameters:
cacheKey
- the cache key to enhancecontextInfo
- context information surrounding sandboxing and multitenant state
-
addPropertiesToCacheKey
protected void addPropertiesToCacheKey(Set<String> currentRequiredPolicyRoots, AuthenticationVendorPrivilegesSummary vendorPrivilegesSummary, com.fasterxml.jackson.databind.node.ObjectNode cacheKey) -
containsAuthorityRoot
-
getCurrentPolicyRequirements
-
getPermissionRoots
-
getVendorRefsByRelevantRestrictedAuthority
protected Map<String,Set<String>> getVendorRefsByRelevantRestrictedAuthority(Set<String> currentRequiredPolicyRoots, AuthenticationVendorPrivilegesSummary vendorPrivilegesSummary) Caching will pretty much only ever be used on read operations, but we can't just filter to vendor restrictions matching the current policy requirements since theContextStateBuilder
's mutability check to setContextState.getMutable()
will perform policy validation against _updates_ as well. Thus, to be safe, we will include all restricted authorities sharing the same _root_ as the current policy requirements.This should eliminate irrelevant roots from the cache key (preventing unnecessarily unique keys) while protecting against a situation where an authentication with READ_* sees the same mutability as an authentication with READ_* and UPDATE_*.
At the same time, it does mean that users with different vendors in each authority will still have different cache keys - however, this is pretty much unavoidable since we can't know what vendor(s) the data is actually being requested from and thus can't filter the restrictions any further.
- Parameters:
currentRequiredPolicyRoots
- the permission roots required by the current policy requirements. Authorities will be filtered to only include those matching these roots.vendorPrivilegesSummary
- the summary of vendor privileges granted to the current authentication- Returns:
- a map of all relevant
restricted authorities
matching the required policy roots
-
getVendorAwareTrackablePolicyUtils
-