You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Georg Kallidis <gk...@cedis.fu-berlin.de> on 2016/07/08 11:11:50 UTC
Turbine 4 Entity User Data Model, Facts and Discussion, Fulcrum Security
Hi,
comparing Turbine4-M1, Turbine4-M2 and current trunk 4.0-SNAPSHOT I took
some notes, which may now get their (right) place in this list to have
some more reviewing and discussion. Sorry for this lengthy mail!
I started with a user model as an example and sketching the situations
with some (pseudo) code. User instantiation is the first place, where a
new user model comes into place - may be a good starting point.
To get a new user instance in
1) turbine-4-m1
2) turbine-4-m2, turbine-4-SNAPSHOT
consider this (pseudocode) examples in
1) org.apache.turbine.services.security.TurbineSecurity.getUserInstance()
{
return getService().getUserInstance()
}
where service could be e.g.
org.apache.turbine.services.security.BaseSecurityService and userInstance
looks like
"return (org.apache.turbine.om.security.User)
getUserClass().newInstance();".
The userClass / userInstance is configured in Turbine configuration e.g.
setting
services.SecurityService.user.class=
org.apache.turbine.om.security.TurbineUser
which is the default user class.
The contract interface is org.apache.turbine.om.security.User.
2) As configured by default
services.SecurityService.user.manager =
org.apache.turbine.services.security.DefaultUserManager
the method getUserInstance has a wrapped user instance:
TurbineUser u = umDelegate.getUserInstance(); (1)
return wrap(u); (2)
(1) umDelegate object implements
org.apache.fulcrum.security.model.turbine.TurbineUserManager (e.g.
org.apache.fulcrum.security.torque.turbine.TorqueTurbineUserManagerImpl.
The userInstance may be delegating further e.g. in
org.apache.fulcrum.security.spi.AbstractUserManager.getUserInstance() and
may look like this
return T user = (T) Class.forName(getClassName()).newInstance();
where the className is configured again in Fulcrum XML configuration e.g.
<userManager><className>... // e.g. Torque generated ORM- class
(2) The wrap code is similar to
return new DefaultUserImpl(user);
It just wraps the user object to keep the contract.
org.apache.turbine.om.security.DefaultUserImpl is an implementation of
org.apache.turbine.om.security.User and wraps
org.apache.fulcrum.security.model.turbine.entity.TurbineUser, e.g. your
ORM class (see below) or as an example
org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl.
The contract interface is <T extends org.apache.turbine.om.security.User>.
Interfaces
This is may be the most important thing to understand, that the same User
interface has been broken up and the semantics changed a little bit.
1) - (org.apache.turbine.om.security.TurbineUser is a class)
org.apache.turbine.om.security.User (password, email, firstName,
lastName, confirmed, createDate, loggedin, accessCounter, perm, temp,
updateLastLogin, tempStorage,permStorage)
-> org.apache.turbine.om.security.SecurityEntity (name, id,
idAsObject)
-> ..
2) org.apache.turbine.om.security.User (confirmed, createDate, loggedin,
accessCounter, perm, temp, updateLastLogin, tempStorage,permStorage)
-> org.apache.fulcrum.security.model.turbine.entity.TurbineUser (-)
-> org.apache.fulcrum.security.entity.ExtendedUser (email,
firstName, lastName, objectData)..
-> org.apache.fulcrum.security.entity.User (password)
-> org.apache.fulcrum.security.entity.SecurityEntity
(name,id)
->
org.apache.fulcrum.security.model.turbine.entity.TurbineUserGroupRoleEntity
(userGroupRoleSet, add-/removeUserGroupRoleSet)
-> ..
As a result there is now NO TurbineUser class any more (except
occasionally a ORM generated class), but instead a new interface (in a
different package) with some additional methods (cft.
TurbineUserGroupRoleEntity) is present. This makes sense as the
TurbineUser is now a special case in Fulcrum Security.
Default classes
1) org.apache.turbine.om.security.TurbineUser implements
org.apache.turbine.om.security.User
2) org.apache.turbine.om.security.DefaultUserImpl implements
org.apache.turbine.om.security.User
Delegates
1) -
2) org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl
(email, firstName, lastName, password, objectData)
Interfaces
-> org.apache.fulcrum.security.model.turbine.entity.TurbineUser
Extended classes
->
org.apache.fulcrum.security.model.turbine.entity.impl.AbstractTurbineSecurityEntityImpl
-> org.apache.fulcrum.security.entity.impl.SecurityEntityImpl
(equals, hashCode, toString)
Interfaces
-> org.apache.fulcrum.security.entity.SecurityEntity (id,
name)
Security/Authentication is now separated and moved into Fulcrum Security.
Caveats
Moved properties
- Email, FirstName, LastName, Password
The getter/setter for email, firstName, lastName, password moved from
org.apache.turbine.om.security.User to the new interface
org.apache.fulcrum.security.model.turbine.entity.TurbineUser. Password is
now kept in a separate interface org.apache.fulcrum.security.entity.User,
the other setter/getter methods are in
org.apache.fulcrum.security.entity.ExtendedUser.
- Name and Id
Old: org.apache.turbine.om.security.SecurityEntity
New: org.apache.fulcrum.security.entity.SecurityEntity
The id getter/setter methods expect now an Object, while in Turbine M1
version an int primitive type was expected. The old version had a special
accessor idAsObject, which is now removed.
The new model properties entityId and entityName correspond probably to id
and name in some way..
Old and New
Turbine Interface: org.apache.turbine.om.security.User
Old implementation class: org.apache.turbine.om.security.TurbineUser
New implementation class: org.apache.turbine.om.security.DefaultUserImpl
New extracted Fulcrum interface:
org.apache.fulcrum.security.model.turbine.entity.TurbineUser
New (example) implementation class:
org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl.
Another implementation class is
org.apache.fulcrum.security.torque.turbine.TorqueAbstractTurbineUser,
which provides some extra methods (delete, databaseName, entityId,
entityName, update, retrieveAttachedObjects, cft.
org.apache.fulcrum.security.torque.TorqueAbstractSecurityEntity).
org.apache.fulcrum.security.entity.ExtendedUser contains
org.apache.fulcrum.security.entity.User (password only getter/setter).
Torque
Building Torque ORM could be done using as base class
org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl
(optionally
org.apache.fulcrum.security.torque.turbine.TorqueAbstractTurbineUser), but
it´s NOT required.
e.g. <table name="turbine_user" idMethod="native"
baseClass="org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl"
(or better just leave it blank)
interface="org.apache.fulcrum.security.model.turbine.entity.TurbineUser">
(To be sure - the generated class in this case is just named TurbineUser
by default ;-)
SecurityService, UserManager
Both could be found in Turbine and Fulcrum. As said in
http://turbine.apache.org/turbine/turbine-4.0-M2/services/security-service.html
. Fulcrum Managers are just delegates and should/could only be used from
Turbine services in Turbine context.
Examples
org.apache.turbine.services.security.SecurityService (userInstance,
getUser..)
org.apache.turbine.services.security.UserManager (userInstance,
authenticate
org.apache.fulcrum.security.SecurityService (userManager, ..)
org.apache.fulcrum.security.UserManager (userInstance, authenticate
Discussion
- No configurable wrapper?
org.apache.turbine.services.security.DefaultUserManager has hard coded
DefaultUserImpl as a wrapper in the wrap method. If its not configurable
you have to setup your onw user manager (extending DefaultUserManager and
overriding the wrap method ) and set it in TR.properties to
services.SecurityService.user.manager.
- Be aware if using TurbineUserImpl the name property is set to "
toLowerCase"!
In
org.apache.fulcrum.security.entity.impl.SecurityEntityImpl.setName(String),
which is used in TurbineUserImpl (and its also in
org.apache.fulcrum.security.torque.TorqueAbstractSecurityEntity.setName(String)
org.apache.fulcrum.security.torque.TorqueAbstractUserManager.getUser(String))
name is set toLowerCase.
If its a kind of legacy support/Turbine feature, it neverthelesse should
be made more explicitely IMO (in my case I need it case sensitive).
- Should entityId, entityName be included in
org.apache.fulcrum.security.entity.SecurityEntity, as it is used by
default in Security Torque? I think there COULD be some confusion about so
many "entity"s (as package, name part, plain property, but not interfaced)
;-)
Don´t hesitate to answer or pointing me to faults, better solutions, etc.
!
Best regards, Georg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Re: Turbine 4 Entity User Data Model, Facts and Discussion, Fulcrum
Security
Posted by Georg Kallidis <gk...@cedis.fu-berlin.de>.
Hi Thomas,
it could go into the wiki, may be as supplement to the already existing
T1-T2 migration guides (
https://wiki.apache.org/turbine/Turbine4/Turbine4.0M2)? I could do this
wiki stuff.
+1 more configurable user managers (case sensititive behaviour, wrapper,
may be also switch off/on saveOnSessionUnbind, which may be not always
what you want).
@entities
The idea is once you have the entities (entityId and entityName) set in
Torque (Torque schema), you could just use id/name (interface
SecurityEntity). May be some short explanation in the wiki would helpful
in this case as well ..
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 05.08.2016 17:03
Betreff: Re: Turbine 4 Entity User Data Model, Facts and
Discussion, Fulcrum Security
On 08.07.16 13:11, Georg Kallidis wrote:
> Hi,
>
> comparing Turbine4-M1, Turbine4-M2 and current trunk 4.0-SNAPSHOT I took
> some notes, which may now get their (right) place in this list to have
> some more reviewing and discussion. Sorry for this lengthy mail!
I think this dpost is a good starting point for a migration guide. You
may want to add it to the Wiki. Any ideas on how to clean up this mess
are very welcome.
> Discussion
> - No configurable wrapper?
> org.apache.turbine.services.security.DefaultUserManager has hard coded
> DefaultUserImpl as a wrapper in the wrap method. If its not configurable
> you have to setup your onw user manager (extending DefaultUserManager
and
> overriding the wrap method ) and set it in TR.properties to
> services.SecurityService.user.manager.
This would be easy to fix. The problem I had when creating all this
stuff is the basic idea of separating the security model from Turbine
and keeping only a few connection points. I may have overlooked this case.
> - Be aware if using TurbineUserImpl the name property is set to "
> toLowerCase"!
>
> In
>
org.apache.fulcrum.security.entity.impl.SecurityEntityImpl.setName(String),
> which is used in TurbineUserImpl (and its also in
>
org.apache.fulcrum.security.torque.TorqueAbstractSecurityEntity.setName(String)
>
org.apache.fulcrum.security.torque.TorqueAbstractUserManager.getUser(String))
> name is set toLowerCase.
>
> If its a kind of legacy support/Turbine feature, it neverthelesse should
> be made more explicitely IMO (in my case I need it case sensitive).
>
This has been the Fulcrum Security concept for all security entities,
users, roles, groups and permissions. I just looked into the Turbine 2.3
code where everything is indeed case sensitive. It didn't matter to me
but I have no problem to revert to case sensitive behavior or - even
better - a configurable behavior.
> - Should entityId, entityName be included in
> org.apache.fulcrum.security.entity.SecurityEntity, as it is used by
> default in Security Torque? I think there COULD be some confusion about
so
> many "entity"s (as package, name part, plain property, but not
interfaced)
> ;-)
This is a kludge to handle exactly the case-insensitivity of the entity
name and the problem of mapping an Integer id in Torque to the generic
Object id in Fulcrum Security. As such, it is
fulcrum-security-torque-specific. I'm open to better solutions.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Turbine 4 Entity User Data Model, Facts and Discussion, Fulcrum
Security
Posted by Thomas Vandahl <tv...@apache.org>.
On 08.07.16 13:11, Georg Kallidis wrote:
> Hi,
>
> comparing Turbine4-M1, Turbine4-M2 and current trunk 4.0-SNAPSHOT I took
> some notes, which may now get their (right) place in this list to have
> some more reviewing and discussion. Sorry for this lengthy mail!
I think this dpost is a good starting point for a migration guide. You
may want to add it to the Wiki. Any ideas on how to clean up this mess
are very welcome.
> Discussion
> - No configurable wrapper?
> org.apache.turbine.services.security.DefaultUserManager has hard coded
> DefaultUserImpl as a wrapper in the wrap method. If its not configurable
> you have to setup your onw user manager (extending DefaultUserManager and
> overriding the wrap method ) and set it in TR.properties to
> services.SecurityService.user.manager.
This would be easy to fix. The problem I had when creating all this
stuff is the basic idea of separating the security model from Turbine
and keeping only a few connection points. I may have overlooked this case.
> - Be aware if using TurbineUserImpl the name property is set to "
> toLowerCase"!
>
> In
> org.apache.fulcrum.security.entity.impl.SecurityEntityImpl.setName(String),
> which is used in TurbineUserImpl (and its also in
> org.apache.fulcrum.security.torque.TorqueAbstractSecurityEntity.setName(String)
> org.apache.fulcrum.security.torque.TorqueAbstractUserManager.getUser(String))
> name is set toLowerCase.
>
> If its a kind of legacy support/Turbine feature, it neverthelesse should
> be made more explicitely IMO (in my case I need it case sensitive).
>
This has been the Fulcrum Security concept for all security entities,
users, roles, groups and permissions. I just looked into the Turbine 2.3
code where everything is indeed case sensitive. It didn't matter to me
but I have no problem to revert to case sensitive behavior or - even
better - a configurable behavior.
> - Should entityId, entityName be included in
> org.apache.fulcrum.security.entity.SecurityEntity, as it is used by
> default in Security Torque? I think there COULD be some confusion about so
> many "entity"s (as package, name part, plain property, but not interfaced)
> ;-)
This is a kludge to handle exactly the case-insensitivity of the entity
name and the problem of mapping an Integer id in Torque to the generic
Object id in Fulcrum Security. As such, it is
fulcrum-security-torque-specific. I'm open to better solutions.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org