Role profiles (with which role you can see and edit which views) currently have to be uploaded manually in the authorization configuration.
Improvement
The configuration should be loaded and imported from WEB-INF/conf/security.xml when the application is initially started. If a new version of the file is delivered during a re-deployment, it should be applied automatically when the new version is initially started.
Consequences
The role profiles must be independent of the component tree of a session for an import at application start. As only authorization configurations for the so-called `CompundSecurityLayout` are stored in the role profiles, configurations may only be saved for these components (or their security ID). Copying the authorization configurations to all components of the subtree must be omitted.
Code migration
The following changes have been made:
- Various previous signatures were changed from Collection or Collection<BoundedRole> to Collection<? extends BoundRole> - i.e. to the interface type for roles. Errors that occurred during typing have been fixed.
- Some signatures have been extended from Wrapper to TLObject.
- The implementation of BoundChecker in LayoutComponent`s has been simplified: Instead of implementing `BoundCheckerDelegate and creating, saving and using a "suitable" delegation, only the appropriate BoundChecker subinterface needs to be implemented:
- LayoutContainerBoundChecker for components that have subcomponents.
- BoundCheckerDelegate only if you really want to forward to another component.
- If a component is marked as securityMaster in a BoundLayout, then the complete check for displayability of the layout (but only this) is forwarded to the marked component (no allow checks with model or command group).
- A persistent authorization configuration for components(PersBoundComp) only exists for exactly those CompoundSecurityLayout components for which the authorization can also be set. All other components within these groups use the same authorization configuration.
- getCurrentObject() in BoundChecker has been replaced by getSecurityObject().
- The rule that a layout can be displayed by components if at least one inner component does not contradict this is no longer applicable. Instead, the layout either checks locally whether it can be displayed (which is usually the case), or it delegates to a specially marked securityMaster component.
- The component configuration option securityProviderClass has been dropped. securityProviderClass="somePrivider" must be replaced by securityObject="ref:somePrivider". As an exception, securityProviderClass="default" must be replaced by securityObject="model" and securityProviderClass="" must be replaced by securityObject="". As a short form, securityProviderClass="securityRoot" can be replaced by securityObject="securityRoot" and securityProviderClass="model" by securityObject="model" and securityProviderClass="path:my.path" by securityObject="path:my.path" and securityProviderClass="null" by securityObject="".