Re: Fortress Properties
> On Oct 28, 2016, at 9:55 AM, Chris Pike wrote: > > FYI, I think I have everything implemented, just need to write some tests to > make sure everything works. Great. If you think you can get 'er done in the next day or so, go for it, otherwise let’s wait until after the release, which is happening this week. Thanks, Shawn
Re: Fortress Properties
FYI, I think I have everything implemented, just need to write some tests to make sure everything works. - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Wednesday, October 26, 2016 9:55:29 AM Subject: Re: Fortress Properties > On Oct 25, 2016, at 7:27 PM, Chris Pike wrote: > > 4. Basically all the methods to support the manager (add/update/delete/read) +1
Re: Fortress Properties
> On Oct 25, 2016, at 7:27 PM, Chris Pike wrote: > > 4. Basically all the methods to support the manager (add/update/delete/read) +1
Re: Fortress Properties
4. Basically all the methods to support the manager (add/update/delete/read) - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Tuesday, October 25, 2016 6:32:58 PM Subject: Re: Fortress Properties > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > Started working on the PropertyMgr interface we discussed, but wanted you to > take a look before I flushed it out all the way > > 1. PropertyMgrImpl - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyMgrImpl.java > - New property specific manager > - Does checkAccess checks based on entity type (i.e. Role add/delete/update > would require AdminMgrImpl.updateRole) OK > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 2. PropertyProvider Interface - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyProvider.java > - Any DAO that supports properties must implement this (see > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/RoleDAO.java) look good > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 3. PropertyP - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyP.java > - Determines which DAO to use based on entity also fine > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 4. New PropertyDAO - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyDAO.java > - Can manage properties on objects that implement PropertyProvider what other methods will go here? Thanks, Shawn
Re: Fortress Properties
> On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > Started working on the PropertyMgr interface we discussed, but wanted you to > take a look before I flushed it out all the way > > 1. PropertyMgrImpl - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyMgrImpl.java > - New property specific manager > - Does checkAccess checks based on entity type (i.e. Role add/delete/update > would require AdminMgrImpl.updateRole) OK > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 2. PropertyProvider Interface - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyProvider.java > - Any DAO that supports properties must implement this (see > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/RoleDAO.java) look good > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 3. PropertyP - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyP.java > - Determines which DAO to use based on entity also fine > On Oct 25, 2016, at 12:34 PM, Chris Pike wrote: > > 4. New PropertyDAO - > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyDAO.java > - Can manage properties on objects that implement PropertyProvider what other methods will go here? Thanks, Shawn
Re: Fortress Properties
Shawn, Started working on the PropertyMgr interface we discussed, but wanted you to take a look before I flushed it out all the way 1. PropertyMgrImpl - https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyMgrImpl.java - New property specific manager - Does checkAccess checks based on entity type (i.e. Role add/delete/update would require AdminMgrImpl.updateRole) 2. PropertyProvider Interface - https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyProvider.java - Any DAO that supports properties must implement this (see https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/RoleDAO.java) 3. PropertyP - https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyP.java - Determines which DAO to use based on entity 4. New PropertyDAO - https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197ManageProperties/src/main/java/org/apache/directory/fortress/core/impl/PropertyDAO.java - Can manage properties on objects that implement PropertyProvider - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Tuesday, October 18, 2016 1:47:17 PM Subject: Re: Fortress Properties > On Oct 18, 2016, at 12:35 PM, Shawn McKinney wrote: > > exposes the physical data model to the caller which is never a good thing. Perhaps I was a bit hasty in saying this. To be clear, the physical data model is still hidden from the caller, although there is a new logical data mapping that has to be shared, i.e. attribute names inside the qb interface. Let’s experiment with the prop searches and if we see opportunities to use this pattern in the future, for new apis, we can do so.
Re: Fortress Properties
> On Oct 18, 2016, at 12:35 PM, Shawn McKinney wrote: > > exposes the physical data model to the caller which is never a good thing. Perhaps I was a bit hasty in saying this. To be clear, the physical data model is still hidden from the caller, although there is a new logical data mapping that has to be shared, i.e. attribute names inside the qb interface. Let’s experiment with the prop searches and if we see opportunities to use this pattern in the future, for new apis, we can do so.
Re: Fortress Properties
> On Oct 18, 2016, at 12:11 PM, Chris Pike wrote: > > I think they should stay in the review managers, since that's where the other > find/search methods reside. Ideally, I think you would deprecate most of the > other find/search methods and use this pattern instead. Negative on the deprecate. Two reasons: 1. The search apis follow incits 359 and arbac02 apis. 2. exposes the physical data model to the caller which is never a good thing. I’m leaning toward a new interface. It could be simple: List find(FortEntity) ForEntity get(FortEntity) and then add the interface to the DAO’s as we discussed before. That is an entity must implement a particular interface to have the querybuilder capability. Anyone who uses this interface knows it is a buyer beware kind of thing, i.e. no guarantees that the data elements don’t change in the future. Where as the review mgr apis are a contract with the outside world. We guarantee that we will add but never change. Shawn
Re: Fortress Properties
I think they should stay in the review managers, since that's where the other find/search methods reside. Ideally, I think you would deprecate most of the other find/search methods and use this pattern instead. - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Tuesday, October 18, 2016 12:53:30 PM Subject: Re: Fortress Properties Not bad. Do you think these methods belong in the reviewmgrs or should we open a new interface? Shawn > On Oct 18, 2016, at 11:47 AM, Chris Pike wrote: > > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197BuilderPattern/src/test/java/org/apache/directory/fortress/core/impl/DelReviewMgrSearchTest.java > > > - Original Message - > From: "Shawn McKinney" > To: fortress@directory.apache.org > Sent: Tuesday, October 18, 2016 12:45:19 PM > Subject: Re: Fortress Properties > >> On Oct 17, 2016, at 8:31 PM, Chris Pike wrote: >> >> If you are interested, I started playing around with a query builder that >> uses the ldap API FilterBuilder internally >> >> https://github.com/PennState/directory-fortress-core-1/tree/feature/fc197BuilderPattern > > Definitely interested. I see that you have exposed the queryBuilder to the > caller: > > List findRoles( AdminRoleQueryBuilder queryBuilder ) > + throws SecurityException; > > What does the client code look like that uses this? > > Shawn
Re: Fortress Properties
Not bad. Do you think these methods belong in the reviewmgrs or should we open a new interface? Shawn > On Oct 18, 2016, at 11:47 AM, Chris Pike wrote: > > https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197BuilderPattern/src/test/java/org/apache/directory/fortress/core/impl/DelReviewMgrSearchTest.java > > > - Original Message - > From: "Shawn McKinney" > To: fortress@directory.apache.org > Sent: Tuesday, October 18, 2016 12:45:19 PM > Subject: Re: Fortress Properties > >> On Oct 17, 2016, at 8:31 PM, Chris Pike wrote: >> >> If you are interested, I started playing around with a query builder that >> uses the ldap API FilterBuilder internally >> >> https://github.com/PennState/directory-fortress-core-1/tree/feature/fc197BuilderPattern > > Definitely interested. I see that you have exposed the queryBuilder to the > caller: > > List findRoles( AdminRoleQueryBuilder queryBuilder ) > + throws SecurityException; > > What does the client code look like that uses this? > > Shawn
Re: Fortress Properties
https://github.com/PennState/directory-fortress-core-1/blob/feature/fc197BuilderPattern/src/test/java/org/apache/directory/fortress/core/impl/DelReviewMgrSearchTest.java - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Tuesday, October 18, 2016 12:45:19 PM Subject: Re: Fortress Properties > On Oct 17, 2016, at 8:31 PM, Chris Pike wrote: > > If you are interested, I started playing around with a query builder that > uses the ldap API FilterBuilder internally > > https://github.com/PennState/directory-fortress-core-1/tree/feature/fc197BuilderPattern Definitely interested. I see that you have exposed the queryBuilder to the caller: List findRoles( AdminRoleQueryBuilder queryBuilder ) + throws SecurityException; What does the client code look like that uses this? Shawn
Re: Fortress Properties
> On Oct 17, 2016, at 8:31 PM, Chris Pike wrote: > > If you are interested, I started playing around with a query builder that > uses the ldap API FilterBuilder internally > > https://github.com/PennState/directory-fortress-core-1/tree/feature/fc197BuilderPattern Definitely interested. I see that you have exposed the queryBuilder to the caller: List findRoles( AdminRoleQueryBuilder queryBuilder ) + throws SecurityException; What does the client code look like that uses this? Shawn
Re: Fortress Properties
If you are interested, I started playing around with a query builder that uses the ldap API FilterBuilder internally https://github.com/PennState/directory-fortress-core-1/tree/feature/fc197BuilderPattern - Original Message - From: "Shawn McKinney" To: fortress@directory.apache.org Sent: Thursday, October 13, 2016 4:53:24 PM Subject: Re: Fortress Properties > On Oct 13, 2016, at 2:54 PM, Chris Pike wrote: > > So how would this work in regards to admin permissions? > > Right now I need AdminMgr.updateUser to update ftProps on a user and > ReviewMgr.findUsers to search for a user > > Are we OK with PropertyManager.update and PropertyManager.search giving me > broader access across many types of objects? Yep. The manager method can either infer or be passed the type which leads to a switch that calls the intended target.
Re: Fortress Properties
> On Oct 13, 2016, at 2:54 PM, Chris Pike wrote: > > So how would this work in regards to admin permissions? > > Right now I need AdminMgr.updateUser to update ftProps on a user and > ReviewMgr.findUsers to search for a user > > Are we OK with PropertyManager.update and PropertyManager.search giving me > broader access across many types of objects? Yep. The manager method can either infer or be passed the type which leads to a switch that calls the intended target.
Re: Fortress Properties
So how would this work in regards to admin permissions?
Right now I need AdminMgr.updateUser to update ftProps on a user and
ReviewMgr.findUsers to search for a user
Are we OK with PropertyManager.update and PropertyManager.search giving me
broader access across many types of objects?
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 1:24:18 PM
Subject: Re: Fortress Properties
> On Oct 13, 2016, at 12:06 PM, Chris Pike wrote:
>
> I created a Jira issue
>
> https://issues.apache.org/jira/browse/FC-197
>
> Would the new search method go on the ReviewMgr?
>
I’m leaning toward creating a new public interface, PropertyMgr that supports
these ops for all entities.
public interface PropertyManager
{
FortEntity add ( FortEntity, String name, String value) throws Property
Exception;
FortEntity update ( FortEntity, String name, String value) throws Property
Exception;
void delete ( FortEntity, String name) throws Property Exception;
String get ( FortEntity, String name) throws Property Exception;
Listsearch ( FortEntity, String name, String value) throws
Property Exception;
}
The ftentity carries user, role, * and we could add a switch based on the child
for determining which tree to point to. Or pass it an enum / other ideas?
>
> On Oct 13, 2016, at 12:06 PM, Chris Pike wrote:
>
> I think the generic method is good for now, long term I really think we
> should really consider adding a query builder pattern so that all new search
> combinations don't require new API methods.
It’s an interesting idea and I’d like to discuss it more. My first thought is
it can already be done with the apache ldap api templates. (I’ve been looking
for an excuse to try them anyway). That is that fortress isn’t a general
purpose api tool, and the ldap api is.
Thanks,
Shawn
Re: Fortress Properties
> On Oct 13, 2016, at 12:06 PM, Chris Pike wrote:
>
> I created a Jira issue
>
> https://issues.apache.org/jira/browse/FC-197
>
> Would the new search method go on the ReviewMgr?
>
I’m leaning toward creating a new public interface, PropertyMgr that supports
these ops for all entities.
public interface PropertyManager
{
FortEntity add ( FortEntity, String name, String value) throws Property
Exception;
FortEntity update ( FortEntity, String name, String value) throws Property
Exception;
void delete ( FortEntity, String name) throws Property Exception;
String get ( FortEntity, String name) throws Property Exception;
Listsearch ( FortEntity, String name, String value) throws
Property Exception;
}
The ftentity carries user, role, * and we could add a switch based on the child
for determining which tree to point to. Or pass it an enum / other ideas?
>
> On Oct 13, 2016, at 12:06 PM, Chris Pike wrote:
>
> I think the generic method is good for now, long term I really think we
> should really consider adding a query builder pattern so that all new search
> combinations don't require new API methods.
It’s an interesting idea and I’d like to discuss it more. My first thought is
it can already be done with the apache ldap api templates. (I’ve been looking
for an excuse to try them anyway). That is that fortress isn’t a general
purpose api tool, and the ldap api is.
Thanks,
Shawn
Re: Fortress Properties
I created a Jira issue
https://issues.apache.org/jira/browse/FC-197
Would the new search method go on the ReviewMgr?
I think the generic method is good for now, long term I really think we should
really consider adding a query builder pattern so that all new search
combinations don't require new API methods.
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 11:07:07 AM
Subject: Re: Fortress Properties
> On Oct 13, 2016, at 9:56 AM, Chris Pike wrote:
>
> I think that will work, but I don't see a way to search by user properties,
> so I still think we need to decide how to expose searching through the API.
Yes to exposing a new search apis for prop names, values (see prev comments)
As for how to search by prop name, something like this….
String searchVal = encodeSafeText( user.getUserId(), GlobalIds.USERID_LEN );
filterbuf.append( GlobalIds.FILTER_PREFIX );
filterbuf.append( Config.getInstance().getProperty( USER_OBJECT_CLASS ) );
filterbuf.append( ")(" );
filterbuf.append( GlobalIds.PROPS );
filterbuf.append( "=" );
filterbuf.append( searchVal );
filterbuf.append( “mypropname” + “*” + ))" );
Re: Fortress Properties
> On Oct 13, 2016, at 9:56 AM, Chris Pike wrote:
>
> I think that will work, but I don't see a way to search by user properties,
> so I still think we need to decide how to expose searching through the API.
Yes to exposing a new search apis for prop names, values (see prev comments)
As for how to search by prop name, something like this….
String searchVal = encodeSafeText( user.getUserId(), GlobalIds.USERID_LEN );
filterbuf.append( GlobalIds.FILTER_PREFIX );
filterbuf.append( Config.getInstance().getProperty( USER_OBJECT_CLASS ) );
filterbuf.append( ")(" );
filterbuf.append( GlobalIds.PROPS );
filterbuf.append( "=" );
filterbuf.append( searchVal );
filterbuf.append( “mypropname” + “*” + ))" );
Re: Fortress Properties
In FPS, we set each ftProps attribute to :. We also include both
the Fortress JAR and the LDAP client JAR. Searching in FPS always uses LDAP
queries, so if you're looking for "country" that starts with "C", you can use:
(ftProps=country:c*)
If you (Pike) want a walk-through of the code we can grab a focus room for 20
minutes.
Steve
“Object-oriented programming is an exceptionally bad idea which could only have
originated in California.” – Edsger Dijkstra
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 11:07:07 AM
Subject: Re: Fortress Properties
> On Oct 13, 2016, at 9:56 AM, Chris Pike wrote:
>
> I think that will work, but I don't see a way to search by user properties,
> so I still think we need to decide how to expose searching through the API.
Yes to exposing a new search apis for prop names, values (see prev comments)
As for how to search by prop name, something like this….
String searchVal = encodeSafeText( user.getUserId(), GlobalIds.USERID_LEN );
filterbuf.append( GlobalIds.FILTER_PREFIX );
filterbuf.append( Config.getInstance().getProperty( USER_OBJECT_CLASS ) );
filterbuf.append( ")(" );
filterbuf.append( GlobalIds.PROPS );
filterbuf.append( "=" );
filterbuf.append( searchVal );
filterbuf.append( “mypropname” + “*” + ))" );
Re: Fortress Properties
> On Oct 13, 2016, at 9:39 AM, Steve Moyer wrote: > > FPS is using the ftProps attribute to store data that isn't in the standard > inetOrgPerson, eduPerson or PSUPerson schemas. We probably should have > created a schema for some of it but it's working well so far. Note that > these are all added to inetOrgPerson (or User via the Fortress library). Yes I recall discussing this some time in the past. Working code wins. :-)
Re: Fortress Properties
> On Oct 13, 2016, at 9:32 AM, Shawn McKinney wrote:
>
>
> public interface Properator (just kidding on name:)
> {
Correction, interface should be package private, and its methods should only be
callable by ‘P’ modules. The Mgr’s can then expose to client as needed. If we
expect a bunch of change, we might create a new manager just for properties, as
opposed to peppering the existing rbac managers with a bunch of utility methods.
interface Properator
{}
Re: Fortress Properties
I think that will work, but I don't see a way to search by user properties, so
I still think we need to decide how to expose searching through the API.
- Original Message -
From: "Steve Moyer"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 10:39:56 AM
Subject: Re: Fortress Properties
FPS is using the ftProps attribute to store data that isn't in the standard
inetOrgPerson, eduPerson or PSUPerson schemas. We probably should have created
a schema for some of it but it's working well so far. Note that these are all
added to inetOrgPerson (or User via the Fortress library).
Steve
“Object-oriented programming is an exceptionally bad idea which could only have
originated in California.” – Edsger Dijkstra
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 10:32:57 AM
Subject: Re: Fortress Properties
for now let’s keep it simple. Follow the way it’s done in User which is
probably the closest to your target and has prop support already in add/update.
Next we can add an interface for DAO’s that have need…
public interface Properator (just kidding on name:)
{
FortEntity add ( FortEntity, String name, String value) throws Property
Exception;
FortEntity update ( FortEntity, String name, String value) throws Property
Exception;
void delete ( FortEntity, String name) throws Property Exception;
String get ( FortEntity, String name) throws Property Exception;
Listsearch ( FortEntity, String name, String value) throws
Property Exception;
}
not all apis need to be supported on every entity nor will they need to be
exposed publically.
Will that work? If so, let’s create a ticket and get this info in there. We
can do this work gradually as needed.
Thanks,
Shawn
> On Oct 13, 2016, at 9:13 AM, Chris Pike wrote:
>
> That sounds like exactly what we want. We would want to add properties and
> have the ability to generically filter by them, but don't need the API to act
> on them in any way.
>
> I guess the question is what is the proper way to update the API to support
> this, for example, to add to AdminRole
>
> 1. Add properties field into object
> - private Props props = new Props();
>
> 2. Update DAO to insert / update / delete properties
>
> 3. Add additional method to allow filtering by properties?
> - public List findRoles(String searchVal, List
> propFilters)
>
> or more generic?
> - List searchEntity(List propFilters, Class
> targetClazz)
>
> or change pattern of searching to more of a query builder?
> - AdminRoleQuery query =
> AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
> "value").addPropertyFilter("key2", "value")
> - public List runAdminRoleQuery(AdminRoleqQuery query)
>
>
>
>
> - Original Message -
> From: "Shawn McKinney"
> To: fortress@directory.apache.org
> Sent: Thursday, October 13, 2016 8:46:04 AM
> Subject: Re: Fortress Properties
>
>> On Oct 12, 2016, at 9:27 PM, Chris Pike wrote:
>>
>> I noticed that all of the fortress entities have the ftProperties object
>> class in LDAP, which means that they can all contain many ftProps. Is that
>> correct? Are the ftProps meant to be user defined defined properties? If so,
>> does the API provide any mechanism to set or query by these properties?
>
> The props aux obj class:
> ## AC2: Fortress Properties Auxiliary Object Class
> objectclass ( ftAxId:2
>NAME 'ftProperties'
>DESC 'Fortress Properties AUX Object Class'
>AUXILIARY
>MAY (
>ftProps
>)
>)
>
> Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
>
> But there is only code written on Config, PermObj and Users which allow some
> level of adding and updating props. No APIs for search at the moment -
> except for Config which of course is just an entity containing properties.
>
> I would be in support of expanding the usage of properties as long as there
> aren’t business rules associated with it. For example it would be fine to
> have apis to perform generic searches on property names / values
>
> List searchEntity(propName, PropValue
>
> I would also support adding code to implement the property capability on the
> other entities, both those listed above and those not.
>
> For me the general idea of a property is that we offer apis for CRUD but
> don’t interpret the value of a property on behalf of the caller. That is the
> caller pulls it back and it is up to it to decide what to do with it.
>
> Shawn
Re: Fortress Properties
FPS is using the ftProps attribute to store data that isn't in the standard
inetOrgPerson, eduPerson or PSUPerson schemas. We probably should have created
a schema for some of it but it's working well so far. Note that these are all
added to inetOrgPerson (or User via the Fortress library).
Steve
“Object-oriented programming is an exceptionally bad idea which could only have
originated in California.” – Edsger Dijkstra
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 10:32:57 AM
Subject: Re: Fortress Properties
for now let’s keep it simple. Follow the way it’s done in User which is
probably the closest to your target and has prop support already in add/update.
Next we can add an interface for DAO’s that have need…
public interface Properator (just kidding on name:)
{
FortEntity add ( FortEntity, String name, String value) throws Property
Exception;
FortEntity update ( FortEntity, String name, String value) throws Property
Exception;
void delete ( FortEntity, String name) throws Property Exception;
String get ( FortEntity, String name) throws Property Exception;
Listsearch ( FortEntity, String name, String value) throws
Property Exception;
}
not all apis need to be supported on every entity nor will they need to be
exposed publically.
Will that work? If so, let’s create a ticket and get this info in there. We
can do this work gradually as needed.
Thanks,
Shawn
> On Oct 13, 2016, at 9:13 AM, Chris Pike wrote:
>
> That sounds like exactly what we want. We would want to add properties and
> have the ability to generically filter by them, but don't need the API to act
> on them in any way.
>
> I guess the question is what is the proper way to update the API to support
> this, for example, to add to AdminRole
>
> 1. Add properties field into object
> - private Props props = new Props();
>
> 2. Update DAO to insert / update / delete properties
>
> 3. Add additional method to allow filtering by properties?
> - public List findRoles(String searchVal, List
> propFilters)
>
> or more generic?
> - List searchEntity(List propFilters, Class
> targetClazz)
>
> or change pattern of searching to more of a query builder?
> - AdminRoleQuery query =
> AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
> "value").addPropertyFilter("key2", "value")
> - public List runAdminRoleQuery(AdminRoleqQuery query)
>
>
>
>
> - Original Message -
> From: "Shawn McKinney"
> To: fortress@directory.apache.org
> Sent: Thursday, October 13, 2016 8:46:04 AM
> Subject: Re: Fortress Properties
>
>> On Oct 12, 2016, at 9:27 PM, Chris Pike wrote:
>>
>> I noticed that all of the fortress entities have the ftProperties object
>> class in LDAP, which means that they can all contain many ftProps. Is that
>> correct? Are the ftProps meant to be user defined defined properties? If so,
>> does the API provide any mechanism to set or query by these properties?
>
> The props aux obj class:
> ## AC2: Fortress Properties Auxiliary Object Class
> objectclass ( ftAxId:2
>NAME 'ftProperties'
>DESC 'Fortress Properties AUX Object Class'
>AUXILIARY
>MAY (
>ftProps
>)
>)
>
> Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
>
> But there is only code written on Config, PermObj and Users which allow some
> level of adding and updating props. No APIs for search at the moment -
> except for Config which of course is just an entity containing properties.
>
> I would be in support of expanding the usage of properties as long as there
> aren’t business rules associated with it. For example it would be fine to
> have apis to perform generic searches on property names / values
>
> List searchEntity(propName, PropValue
>
> I would also support adding code to implement the property capability on the
> other entities, both those listed above and those not.
>
> For me the general idea of a property is that we offer apis for CRUD but
> don’t interpret the value of a property on behalf of the caller. That is the
> caller pulls it back and it is up to it to decide what to do with it.
>
> Shawn
Re: Fortress Properties
for now let’s keep it simple. Follow the way it’s done in User which is
probably the closest to your target and has prop support already in add/update.
Next we can add an interface for DAO’s that have need…
public interface Properator (just kidding on name:)
{
FortEntity add ( FortEntity, String name, String value) throws Property
Exception;
FortEntity update ( FortEntity, String name, String value) throws Property
Exception;
void delete ( FortEntity, String name) throws Property Exception;
String get ( FortEntity, String name) throws Property Exception;
Listsearch ( FortEntity, String name, String value) throws
Property Exception;
}
not all apis need to be supported on every entity nor will they need to be
exposed publically.
Will that work? If so, let’s create a ticket and get this info in there. We
can do this work gradually as needed.
Thanks,
Shawn
> On Oct 13, 2016, at 9:13 AM, Chris Pike wrote:
>
> That sounds like exactly what we want. We would want to add properties and
> have the ability to generically filter by them, but don't need the API to act
> on them in any way.
>
> I guess the question is what is the proper way to update the API to support
> this, for example, to add to AdminRole
>
> 1. Add properties field into object
> - private Props props = new Props();
>
> 2. Update DAO to insert / update / delete properties
>
> 3. Add additional method to allow filtering by properties?
> - public List findRoles(String searchVal, List
> propFilters)
>
> or more generic?
> - List searchEntity(List propFilters, Class
> targetClazz)
>
> or change pattern of searching to more of a query builder?
> - AdminRoleQuery query =
> AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
> "value").addPropertyFilter("key2", "value")
> - public List runAdminRoleQuery(AdminRoleqQuery query)
>
>
>
>
> - Original Message -
> From: "Shawn McKinney"
> To: fortress@directory.apache.org
> Sent: Thursday, October 13, 2016 8:46:04 AM
> Subject: Re: Fortress Properties
>
>> On Oct 12, 2016, at 9:27 PM, Chris Pike wrote:
>>
>> I noticed that all of the fortress entities have the ftProperties object
>> class in LDAP, which means that they can all contain many ftProps. Is that
>> correct? Are the ftProps meant to be user defined defined properties? If so,
>> does the API provide any mechanism to set or query by these properties?
>
> The props aux obj class:
> ## AC2: Fortress Properties Auxiliary Object Class
> objectclass ( ftAxId:2
>NAME 'ftProperties'
>DESC 'Fortress Properties AUX Object Class'
>AUXILIARY
>MAY (
>ftProps
>)
>)
>
> Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
>
> But there is only code written on Config, PermObj and Users which allow some
> level of adding and updating props. No APIs for search at the moment -
> except for Config which of course is just an entity containing properties.
>
> I would be in support of expanding the usage of properties as long as there
> aren’t business rules associated with it. For example it would be fine to
> have apis to perform generic searches on property names / values
>
> List searchEntity(propName, PropValue
>
> I would also support adding code to implement the property capability on the
> other entities, both those listed above and those not.
>
> For me the general idea of a property is that we offer apis for CRUD but
> don’t interpret the value of a property on behalf of the caller. That is the
> caller pulls it back and it is up to it to decide what to do with it.
>
> Shawn
Re: Fortress Properties
That sounds like exactly what we want. We would want to add properties and have
the ability to generically filter by them, but don't need the API to act on
them in any way.
I guess the question is what is the proper way to update the API to support
this, for example, to add to AdminRole
1. Add properties field into object
- private Props props = new Props();
2. Update DAO to insert / update / delete properties
3. Add additional method to allow filtering by properties?
- public List findRoles(String searchVal, List
propFilters)
or more generic?
- List searchEntity(List propFilters, Class
targetClazz)
or change pattern of searching to more of a query builder?
- AdminRoleQuery query =
AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
"value").addPropertyFilter("key2", "value")
- public List runAdminRoleQuery(AdminRoleqQuery query)
- Original Message -
From: "Shawn McKinney"
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 8:46:04 AM
Subject: Re: Fortress Properties
> On Oct 12, 2016, at 9:27 PM, Chris Pike wrote:
>
> I noticed that all of the fortress entities have the ftProperties object
> class in LDAP, which means that they can all contain many ftProps. Is that
> correct? Are the ftProps meant to be user defined defined properties? If so,
> does the API provide any mechanism to set or query by these properties?
The props aux obj class:
## AC2: Fortress Properties Auxiliary Object Class
objectclass ( ftAxId:2
NAME 'ftProperties'
DESC 'Fortress Properties AUX Object Class'
AUXILIARY
MAY (
ftProps
)
)
Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
But there is only code written on Config, PermObj and Users which allow some
level of adding and updating props. No APIs for search at the moment - except
for Config which of course is just an entity containing properties.
I would be in support of expanding the usage of properties as long as there
aren’t business rules associated with it. For example it would be fine to have
apis to perform generic searches on property names / values
List searchEntity(propName, PropValue
I would also support adding code to implement the property capability on the
other entities, both those listed above and those not.
For me the general idea of a property is that we offer apis for CRUD but don’t
interpret the value of a property on behalf of the caller. That is the caller
pulls it back and it is up to it to decide what to do with it.
Shawn
Re: Fortress Properties
> On Oct 12, 2016, at 9:27 PM, Chris Pike wrote:
>
> I noticed that all of the fortress entities have the ftProperties object
> class in LDAP, which means that they can all contain many ftProps. Is that
> correct? Are the ftProps meant to be user defined defined properties? If so,
> does the API provide any mechanism to set or query by these properties?
The props aux obj class:
## AC2: Fortress Properties Auxiliary Object Class
objectclass ( ftAxId:2
NAME 'ftProperties'
DESC 'Fortress Properties AUX Object Class'
AUXILIARY
MAY (
ftProps
)
)
Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.
But there is only code written on Config, PermObj and Users which allow some
level of adding and updating props. No APIs for search at the moment - except
for Config which of course is just an entity containing properties.
I would be in support of expanding the usage of properties as long as there
aren’t business rules associated with it. For example it would be fine to have
apis to perform generic searches on property names / values
List searchEntity(propName, PropValue
I would also support adding code to implement the property capability on the
other entities, both those listed above and those not.
For me the general idea of a property is that we offer apis for CRUD but don’t
interpret the value of a property on behalf of the caller. That is the caller
pulls it back and it is up to it to decide what to do with it.
Shawn
Fortress Properties
I noticed that all of the fortress entities have the ftProperties object class in LDAP, which means that they can all contain many ftProps. Is that correct? Are the ftProps meant to be user defined defined properties? If so, does the API provide any mechanism to set or query by these properties?
