You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Jan Sindberg <js...@autorola.com> on 2015/11/04 16:13:02 UTC
Repository of Permissions / Permission public setters
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?
Re: Repository of Permissions / Permission public setters
Posted by Shawn McKinney <sm...@apache.org>.
> On Nov 11, 2015, at 3:44 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> I've had similar thoughts about how Shiro and Fortress could play well together. Shiro provides a nicer set of Annotations and access check methods that work similar to the way that we're using the @RolesAllowed annotation in JavaEE. I'm also interested to see what's in the new Security API in JavaEE 8, but haven't had time to investigate yet.
Chris,
I’ll take a look at Shiro and try to figure out how to do it - my assumption is it’s a minimal effort. Ditto on interest about the new Java security API. I have no aversion to using the other APIs as long as we can map back to the fortress policies in LDAP.
Shawn
Re: Repository of Permissions / Permission public setters
Posted by Christopher Harm <cr...@psu.edu>.
Shawn,
I've had similar thoughts about how Shiro and Fortress could play well together. Shiro provides a nicer set of Annotations and access check methods that work similar to the way that we're using the @RolesAllowed annotation in JavaEE. I'm also interested to see what's in the new Security API in JavaEE 8, but haven't had time to investigate yet.
-Chris
--
Christopher Harm
Penn State University
AIS/ITS
221 Technology Support Building
300 Science Park Road
State College, PA 16803
814-863-3366
From: "Shawn McKinney" <sm...@apache.org>
To: "Fortress Mailing List" <fo...@directory.apache.org>
Sent: Wednesday, November 11, 2015 12:29:21 PM
Subject: Re: Repository of Permissions / Permission public setters
> On Nov 10, 2015, at 1:52 AM, Jan Sindberg <js...@autorola.com> wrote:
>
> Well, it is mostly a question of personal taste, architectural style and secure programming. If a Permission is really a value-object, then it should be immutable once created (personal opinion). I could use annotations to make my objects immutable.
> I show my own wrapper below.
>
Yes I can see why you say that. I never worried too much about (before) it because Fortress treats perms as a value object (noun) instead of a privilege to an action (verb). There are no heavy resources being consumed during construction. The permission gets created, used in a checkAccess and thrown away (usually). There is no real value in caching because it relatively inexpensive to create a new one.
On the other hand, there is no reason it shouldn’t be made immutable. That is I can’t see a use case where we’d change one of the attributes after it first gets setup.
>
> On Nov 10, 2015, at 1:52 AM, Jan Sindberg <js...@autorola.com> wrote:
>
>>
>> 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
>
> Still new to session management and thread issues. I am looking at Shiro and consider if I want to use that as API and Apache Fortress as Realm. Shiro handles sessions and also allows multiple Realms.
> Here is what my current homebrew experiment looks like.:
>
> // Singleton to hold instances
> // setPrincipal should be called where users are logged in and out.
> public class SecurityUtil
> {
> private static SecurityUtil ourInstance = new SecurityUtil();
> ThreadLocal<Principal> infoThreadLocal = new InheritableThreadLocal();
>
> public static SecurityUtil getInstance()
> {
> return ourInstance;
> }
>
> private SecurityUtil()
> {
> }
>
> public void setPrincipal(Principal _principal)
> {
> this.infoThreadLocal.set(_principal);
> }
>
> public Principal getPrincipal()
> {
> return (Principal) this.infoThreadLocal.get();
> }
>
> /**
> * Todo
> * @return
> */
> public boolean initializePrincipal()
> {
> return false;
> }
> }
>
> // The principal holds the session and the accessMgr.
> // This allows for each principal to have individually configured accessMgr.
> // You might want to subclass this to add you own user object, etc.
> public class Principal
> {
> private AccessMgr accessMgr;
> private Session session;
>
> protected AccessMgr getAccessMgr()
> {
> return accessMgr;
> }
>
> protected void setAccessMgr(AccessMgr _accessMgr)
> {
> accessMgr = _accessMgr;
> }
>
> public Session getSession()
> {
> return session;
> }
>
> public void setSession(Session _session)
> {
> session = _session;
> }
>
> // Should not be used outside this package
> // See PermissionObject
> public protected checkAccess(Permission _permission)
> {
> // Do audit log ?
> //...
>
> boolean result = false;
> if (session.isAuthenticated())
> {
> try
> {
> result = accessMgr.checkAccess(session, _permission);
> }
> catch (org.apache.directory.fortress.core.SecurityException e)
> {
> e.printStackTrace(); //todo
> }
> }
> return result;
> }
> }
>
> // A simple class to express a permission with an operation
> public class PermissionObject
> {
> private String objName;
> private String opName;
> private Permission permission;
>
> public PermissionObject(String _objName, String _opName)
> {
> objName = _objName;
> opName = _opName;
> permission = new Permission(_objName, _opName);
> }
>
> public boolean authZ()
> {
> boolean result = false;
> Principal principal = SecurityUtil.getInstance().getPrincipal();
> if (principal != null)
> {
> result = principal.checkAccess(permission);
> }
> return result;
> }
>
> public boolean authZ(String _objId)
> {
> boolean result = false;
> Principal principal = SecurityUtil.getInstance().getPrincipal();
> if (principal != null)
> {
> result = principal.checkAccess(new Permission(objName, opName, _objId));
> }
> return result;
> }
> }
>
> // A collection of permissions.
> // This is the application or domain specific permissions to be used
> public class FMPerm_Letters
> {
> private static String name = "LETTERS";
> public static final PermissionObject EDIT_CONSIGNMENT_LETTER = new PermissionObject(name, "EDIT_CONSIGNMENT_LETTER");
> public static final PermissionObject EDIT_WITHDRAWAL_LETTER = new PermissionObject(name, "EDIT_WITHDRAWAL_LETTER");
> ....
> }
>
> // A very simplified example of usage
> public class SomeDataObject {
>
> public Button getEditConsignmentLetterButton()
> {
> If (EDIT_CONSIGNMENT_LETTER.authZ()) {
> return ButtonBuilder.getEditConsignmentLetter();
> }
> else {
> return null;
> }
> }
> }
>
> A nicer solution would be to use annotations on the getter-methods instead. But that's an example for another time. The inner workings of the annotation would be somewhat similar but determining return value by reflection and application specific requirements.
I’ll have to study your example a bit before I can comment too much. It would help if you could add some commentary about it. What are the requirements that are missing, or otherwise not being satisfied unless one uses the system in this way?
What I can say (now) is I’ve been thinking lately about using apache shiro as the api (policy enforcement) but mapping the policy decision point to fortress - meaning it still uses fortress style rbac as the back end. That way we take advantage of shiro’s integration with more platforms while still retaining fortress style administration and ldap management capability.
Shawn
Re: Repository of Permissions / Permission public setters
Posted by Shawn McKinney <sm...@apache.org>.
> On Nov 10, 2015, at 1:52 AM, Jan Sindberg <js...@autorola.com> wrote:
>
> Well, it is mostly a question of personal taste, architectural style and secure programming. If a Permission is really a value-object, then it should be immutable once created (personal opinion). I could use annotations to make my objects immutable.
> I show my own wrapper below.
>
Yes I can see why you say that. I never worried too much about (before) it because Fortress treats perms as a value object (noun) instead of a privilege to an action (verb). There are no heavy resources being consumed during construction. The permission gets created, used in a checkAccess and thrown away (usually). There is no real value in caching because it relatively inexpensive to create a new one.
On the other hand, there is no reason it shouldn’t be made immutable. That is I can’t see a use case where we’d change one of the attributes after it first gets setup.
>
> On Nov 10, 2015, at 1:52 AM, Jan Sindberg <js...@autorola.com> wrote:
>
>>
>> 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
>
> Still new to session management and thread issues. I am looking at Shiro and consider if I want to use that as API and Apache Fortress as Realm. Shiro handles sessions and also allows multiple Realms.
> Here is what my current homebrew experiment looks like.:
>
> // Singleton to hold instances
> // setPrincipal should be called where users are logged in and out.
> public class SecurityUtil
> {
> private static SecurityUtil ourInstance = new SecurityUtil();
> ThreadLocal<Principal> infoThreadLocal = new InheritableThreadLocal();
>
> public static SecurityUtil getInstance()
> {
> return ourInstance;
> }
>
> private SecurityUtil()
> {
> }
>
> public void setPrincipal(Principal _principal)
> {
> this.infoThreadLocal.set(_principal);
> }
>
> public Principal getPrincipal()
> {
> return (Principal) this.infoThreadLocal.get();
> }
>
> /**
> * Todo
> * @return
> */
> public boolean initializePrincipal()
> {
> return false;
> }
> }
>
> // The principal holds the session and the accessMgr.
> // This allows for each principal to have individually configured accessMgr.
> // You might want to subclass this to add you own user object, etc.
> public class Principal
> {
> private AccessMgr accessMgr;
> private Session session;
>
> protected AccessMgr getAccessMgr()
> {
> return accessMgr;
> }
>
> protected void setAccessMgr(AccessMgr _accessMgr)
> {
> accessMgr = _accessMgr;
> }
>
> public Session getSession()
> {
> return session;
> }
>
> public void setSession(Session _session)
> {
> session = _session;
> }
>
> // Should not be used outside this package
> // See PermissionObject
> public protected checkAccess(Permission _permission)
> {
> // Do audit log ?
> //...
>
> boolean result = false;
> if (session.isAuthenticated())
> {
> try
> {
> result = accessMgr.checkAccess(session, _permission);
> }
> catch (org.apache.directory.fortress.core.SecurityException e)
> {
> e.printStackTrace(); //todo
> }
> }
> return result;
> }
> }
>
> // A simple class to express a permission with an operation
> public class PermissionObject
> {
> private String objName;
> private String opName;
> private Permission permission;
>
> public PermissionObject(String _objName, String _opName)
> {
> objName = _objName;
> opName = _opName;
> permission = new Permission(_objName, _opName);
> }
>
> public boolean authZ()
> {
> boolean result = false;
> Principal principal = SecurityUtil.getInstance().getPrincipal();
> if (principal != null)
> {
> result = principal.checkAccess(permission);
> }
> return result;
> }
>
> public boolean authZ(String _objId)
> {
> boolean result = false;
> Principal principal = SecurityUtil.getInstance().getPrincipal();
> if (principal != null)
> {
> result = principal.checkAccess(new Permission(objName, opName, _objId));
> }
> return result;
> }
> }
>
> // A collection of permissions.
> // This is the application or domain specific permissions to be used
> public class FMPerm_Letters
> {
> private static String name = "LETTERS";
> public static final PermissionObject EDIT_CONSIGNMENT_LETTER = new PermissionObject(name, "EDIT_CONSIGNMENT_LETTER");
> public static final PermissionObject EDIT_WITHDRAWAL_LETTER = new PermissionObject(name, "EDIT_WITHDRAWAL_LETTER");
> ....
> }
>
> // A very simplified example of usage
> public class SomeDataObject {
>
> public Button getEditConsignmentLetterButton()
> {
> If (EDIT_CONSIGNMENT_LETTER.authZ()) {
> return ButtonBuilder.getEditConsignmentLetter();
> }
> else {
> return null;
> }
> }
> }
>
> A nicer solution would be to use annotations on the getter-methods instead. But that's an example for another time. The inner workings of the annotation would be somewhat similar but determining return value by reflection and application specific requirements.
I’ll have to study your example a bit before I can comment too much. It would help if you could add some commentary about it. What are the requirements that are missing, or otherwise not being satisfied unless one uses the system in this way?
What I can say (now) is I’ve been thinking lately about using apache shiro as the api (policy enforcement) but mapping the policy decision point to fortress - meaning it still uses fortress style rbac as the back end. That way we take advantage of shiro’s integration with more platforms while still retaining fortress style administration and ldap management capability.
Shawn
SV: Repository of Permissions / Permission public setters
Posted by Jan Sindberg <js...@autorola.com>.
> -----Oprindelig meddelelse-----
> Fra: Shawn McKinney [mailto:smckinney@apache.org]
> Sendt: 5. november 2015 17:25
> Til: fortress@directory.apache.org
> Emne: Re: Repository of Permissions / Permission public setters
>
>
> > On Nov 5, 2015, at 2:52 AM, Jan Sindberg <js...@autorola.com> 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?
Well, it is mostly a question of personal taste, architectural style and secure programming. If a Permission is really a value-object, then it should be immutable once created (personal opinion). I could use annotations to make my objects immutable.
I show my own wrapper below.
>
> 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
Still new to session management and thread issues. I am looking at Shiro and consider if I want to use that as API and Apache Fortress as Realm. Shiro handles sessions and also allows multiple Realms.
Here is what my current homebrew experiment looks like.:
// Singleton to hold instances
// setPrincipal should be called where users are logged in and out.
public class SecurityUtil
{
private static SecurityUtil ourInstance = new SecurityUtil();
ThreadLocal<Principal> infoThreadLocal = new InheritableThreadLocal();
public static SecurityUtil getInstance()
{
return ourInstance;
}
private SecurityUtil()
{
}
public void setPrincipal(Principal _principal)
{
this.infoThreadLocal.set(_principal);
}
public Principal getPrincipal()
{
return (Principal) this.infoThreadLocal.get();
}
/**
* Todo
* @return
*/
public boolean initializePrincipal()
{
return false;
}
}
// The principal holds the session and the accessMgr.
// This allows for each principal to have individually configured accessMgr.
// You might want to subclass this to add you own user object, etc.
public class Principal
{
private AccessMgr accessMgr;
private Session session;
protected AccessMgr getAccessMgr()
{
return accessMgr;
}
protected void setAccessMgr(AccessMgr _accessMgr)
{
accessMgr = _accessMgr;
}
public Session getSession()
{
return session;
}
public void setSession(Session _session)
{
session = _session;
}
// Should not be used outside this package
// See PermissionObject
public protected checkAccess(Permission _permission)
{
// Do audit log ?
//...
boolean result = false;
if (session.isAuthenticated())
{
try
{
result = accessMgr.checkAccess(session, _permission);
}
catch (org.apache.directory.fortress.core.SecurityException e)
{
e.printStackTrace(); //todo
}
}
return result;
}
}
// A simple class to express a permission with an operation
public class PermissionObject
{
private String objName;
private String opName;
private Permission permission;
public PermissionObject(String _objName, String _opName)
{
objName = _objName;
opName = _opName;
permission = new Permission(_objName, _opName);
}
public boolean authZ()
{
boolean result = false;
Principal principal = SecurityUtil.getInstance().getPrincipal();
if (principal != null)
{
result = principal.checkAccess(permission);
}
return result;
}
public boolean authZ(String _objId)
{
boolean result = false;
Principal principal = SecurityUtil.getInstance().getPrincipal();
if (principal != null)
{
result = principal.checkAccess(new Permission(objName, opName, _objId));
}
return result;
}
}
// A collection of permissions.
// This is the application or domain specific permissions to be used
public class FMPerm_Letters
{
private static String name = "LETTERS";
public static final PermissionObject EDIT_CONSIGNMENT_LETTER = new PermissionObject(name, "EDIT_CONSIGNMENT_LETTER");
public static final PermissionObject EDIT_WITHDRAWAL_LETTER = new PermissionObject(name, "EDIT_WITHDRAWAL_LETTER");
....
}
// A very simplified example of usage
public class SomeDataObject {
public Button getEditConsignmentLetterButton()
{
If (EDIT_CONSIGNMENT_LETTER.authZ()) {
return ButtonBuilder.getEditConsignmentLetter();
}
else {
return null;
}
}
}
A nicer solution would be to use annotations on the getter-methods instead. But that's an example for another time. The inner workings of the annotation would be somewhat similar but determining return value by reflection and application specific requirements.
Re: Repository of Permissions / Permission public setters
Posted by Shawn McKinney <sm...@apache.org>.
> On Nov 5, 2015, at 2:52 AM, Jan Sindberg <js...@autorola.com> 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
SV: Repository of Permissions / Permission public setters
Posted by Jan Sindberg <js...@autorola.com>.
> -----Oprindelig meddelelse-----
> Fra: Shawn McKinney [mailto:smckinney@apache.org]
> Sendt: 4. november 2015 23:06
> Til: fortress@directory.apache.org
> Emne: Re: Repository of Permissions / Permission public setters
>
>
> > On Nov 4, 2015, at 9:13 AM, Jan Sindberg <js...@autorola.com> 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 :-)
Re: Repository of Permissions / Permission public setters
Posted by Shawn McKinney <sm...@apache.org>.
> On Nov 4, 2015, at 9:13 AM, Jan Sindberg <js...@autorola.com> 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