Every example I’ve seen in the Seam literature (even the new Seam in Action and the Seam 2.0 ref pdf) have hard-coded references in the method call for the role name. Example below from ref pdf:
<restrict>#{s:hasRole('admin')}</restrict>I don’t like the hard-coding for obvious reasons. So what I’d like to do is pull out the explicit references from the hasRole methods and embed them in a properties or some other resource bundle, etc. or even a db table(s).
The names of the roles and requirements for which role(s) has access to which pages will most likely not change very often so a props file may be sufficient. Counter-argument to this is that if/when we do need to change the role/page access config, then we can do so without dev/test/deploy of the Seam app. Although you’d probably want to test it anyway to be safe.
So basically the new implementation would be something like:
<restrict>#{s:hasRole(myRestrictComponent.getReportsAccessList)}</restrict>myRestrictComponent.getReportsAccessList returns a String like “’roleA’, ‘roleB’, ‘roleC’” and if the current identity object has any of those roles in it, then the current user will see the page requested. Otherwise, re-directed to error.xhtml.
design consideration would be do we add the method to each SFSB for the JSF or have one common SLSB for all JSF’s with all the getFoobarAccessList methods? I vote centralized SLSB. I’m not sure using the foobar-config.properties would be appropriate for this scenario. And if we go db table(s), then SLSB would be a good bet.
any opinions? how is hasRole typically implemented in a production Seam app?
