> -----Oprindelig meddelelse-----
> Fra: Shawn McKinney [mailto:[email protected]]
> Sendt: 4. november 2015 23:06
> Til: [email protected]
> Emne: Re: Repository of Permissions / Permission public setters
>
>
> > On Nov 4, 2015, at 9:13 AM, Jan Sindberg <[email protected]> wrote:
> >
> > I was thinking of centralizing the permissions. For instance as a
> > Public class Permission_Letters { static final String name =
> > "LETTERS"; static final Permission EDIT_DAMAGE_LETTERS = new
> > Permission(name, "EDIT_DAMAGE_LETTERS"); ...
> > ...
> > }
> >
> > Where there must be a check the code can refer to this permission without
> making a new Permission and without copying strings all over the source.
> > ...
> > If (accessMgr.checkAccess(session, Permission_Letters.
> EDIT_DAMAGE_LETTERS)) {
> > // Do stuff
> > }
> > ...
> > In friendly code that is all fine and good, but one could "accidentally"
> rename the object and operation through the public setters on any
> permission, completely changing the meaning.
> > If I want to secure my code, instead of static fields I need to do static
> methods which return a new Permission object each time.
> > It's probably not too expensive to create a new object each time there
> should be a permission-check, but I would still like to suggest dedicated
> constructors and no setters, or at least package scoped setters where
> possible. What do you think?
>
> Jan,
>
> Still trying to understand your requirements here.
>
> What is the rationale of wrapping a fortress Permission instance with another
> class like Permission_Letters? What does this buy us - convenience, security,
> flexibility, enhanced capability? I’ll need to understand this before I can
> comment further on what I think about the idea or how to implement it.
>
> Thanks
>
> Shawn
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)
Thanks for your quick answers :-)
