> On Nov 5, 2015, at 2:52 AM, Jan Sindberg <[email protected]> wrote: > > Each permission will have to be checked more than one place. Multiple places > when generating the GUI - not to show fields, buttons, action-menus, or even > complete lists of "assets". But still malicious users could have knowledge of > the direct action-urls and therefore all related serverside methods must be > access-checked (similar to javascript validation must be repeated > serverside). > > I want to centralize in order to : > 1) Have only one place to do changes in case an object or operation name > changes or is misspelled. > 2) Creating better semantics in the access-check. > 3) Having better code-completion and refactoring help in the IDE (Eclipse, > Intellij, etc.) > 4) Making it easier to find all permissions related to a specific object. > > Looking at Role Engineering, it seems to me that it is a good practice to > center roles and operations around objects. When trying to think about our > domain, it makes good sense (for me) to group permissions around the object > they are related to. > So my example is about ease of use and understanding our domain. Ease of > coding, refactoring and extending. Reducing the risk of making errors and > centralizing error-correction. > > Just getting an idea. If I can get hold of the accessMgr and the session > globally, I could even do like this. > If (Permission_Letters.checkEditDamageLetters()) { > // Do stuff > } > > (assuming I can get to the accessMgr and the session inside the > checkXXX-method)
OK, I am tracking with you now and yes your ideas makes good sense to me. Now, for my next question, would a new permission wrapper class or extension to the accessmgr help here? Regarding your question about using/storing manager and session objects globally… All of the manager objects are threadsafe, may be created, held, and reused across multiple thread contexts without concern. On the other hand, they are also relatively cheap to create, so no real concern if you want to create and throw them away on every usage. One word of caution wrt multienancy - manager’s are scoped to a single tenant, and your usages need to be aware of that scoping, if processing in a multitenant context. The session object is not thread safe (like all other fortress entities) so bear that in mind as you build your system. Hope this helps, Shawn
