You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Leon Messerschmidt <le...@opticode.co.za> on 2001/03/27 12:38:57 UTC
Security and ACL
Hi,
Directed to Rafal, as the (un)official security guy.
A colleague pointed out a situation that would happen in places where people
share computers - like schools & universities. Say a user has logged. A
second user sees something cool in the app and also wants to log in - he
presses the back button and enters his details on the login screen.
Because the ACL is stored in the session the second user will end up with
the ACL of the first, unless you call a data.setACL (null) in the login
action. Even when calling data.setACL (null) the second user (by looking at
the order of events in Turbine.java) will have the stale ACL when the first
screen is displayed. Clicking back and login _always_ results in a stale
ACL for at least one screen.
The solution, as pointed out to me, was to add a getACL() method to the user
interface and to execute the AccessControler from there. This prevents the
state ACL problem form occurring, and it simplifies both code in Turbine
(extra code in Turbine.java) and actions written by users (you do not need
to explicitly call data.setACL (null) on login or logout).
We can mark the data.getACL() method as deprecated and in the mean time
simply return data.getUser().getACL(). Eventually everybody should only be
calling data.getUser().getACL().
If it is ok with everybody I will volunteer to do this.
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by John McNally <jm...@collab.net>.
This suggestion will probably get a -1 from both of you, but I am
wondering if it could solve the problem "temporarily":
TurbineUser (and any other user implementation) could remove the acl
from the session in its valueUnbound (or valueBound). It's pretty ugly,
but does not mess with the current interfaces.
John McNally
Leon Messerschmidt wrote:
>
> Hi Rafal,
>
> > > screen is displayed. Clicking back and login _always_ results in a
> stale
> > > ACL for at least one screen.
> >
> > The login action is executed before the screen, so the screen will see
> > the
> > session cleared, or I missing
>
> I fixed that but I then realized that I have two actions that will result in
> a login. A normal loginUser action and I automatically login a user when he
> registers with a registerUser action. Setting either in the TR.properties
> results in the other to be able to get an invalid session object.
>
> My colleague stumbled across the same problem in another way. He has a
> fairly complex admin system and he wants to "simulate" a users login to an
> administrator. For this he wrote an action code for changing the user.
> Again this does not go through the default login action and it breaks the
> security system.
>
> I'm there will be other ways of breaking the current system, because there
> is no way of validating that the ACL in the session does in fact belong to
> the user that is logged in.
>
> > > The solution, as pointed out to me, was to add a getACL() method to the
> user
> > > interface and to execute the AccessControler from there. This prevents
> the
> > > state ACL problem form occurring, and it simplifies both code in Turbine
> > > (extra code in Turbine.java) and actions written by users (you do not
> need
> > > to explicitly call data.setACL (null) on login or logout).
> >
> > This would mean that the ACL will have to be rebuilt on each hit. This
> > means
> > accessing the database/directory server and additional computations. I'd
> > much
> > prefer if this information was cached in the user's session for
> > performance
> > reasons.
>
> It won't need to build on every hit. Something like this work:
>
> (if this.acl == null)
> {
> // get ACL from AccessController
> }
> return acl
>
> > I'd say - code your Login/Logout actions right, otherwise you'll get
> > wrong
> > behaviour. We shouldn't sacrifice performance only to support sloppy
> > programing
> > at the same time.
> >
> > I also don't think that including getACL() method into User interface is
> > a good idea, because I see no reason to couple these two. The ACL object
> > depends on an User object, but the oposite is not true - you can have an
> > User object without ACL, or you can have an alternative access control
> > system, that depends on Turbine User interface.
>
> The ACL gets build the an AccessControler action. If you require an
> alternative security implementation the best place to add this would be the
> AccessControler.
>
> I don't think your above mentioned idea allows for pluggable implementations
> without breaking code. You need to have a standard interface for your app
> to query roles/permissions regardless of the backend or security
> implementation.
>
> > > We can mark the data.getACL() method as deprecated and in the mean time
> > > simply return data.getUser().getACL(). Eventually everybody should only
> be
> > > calling data.getUser().getACL().
> > >
> > > If it is ok with everybody I will volunteer to do this.
> >
> > Thanks, but I think what we need is better documentation of Login/Logout
> > behaviour in the Javadocs, and possibly xdocs too.
>
> I think there is more serious problems than just lack of documentation.
>
> > Rafal
> >
> > --
> > Rafal Krzewski
> > Senior Internet Developer
> > mailto:Rafal.Krzewski@e-point.pl
> > +48 22 8534830 http://e-point.pl
>
> ~ Leon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Leon Messerschmidt <le...@opticode.co.za>.
> My approach to this problem is somewhat reversed: In the AccessControler
> action, if there is no User in the session, load a real "guest" user
> from
> the DB instead of anonymous user. This way you can assign permissions to
> this user. In this approach, assiging rights to not logged in users
> requires modyfing the AccessControler only (which is a plugable
> component
> by desingn) and not the framework.
This is a much better solution. I think I'll be implementing it next week
:-)
> If our goal is separation of User/user management from the ACL/security
> service
> (note that the possible security services may differ at the *interface*
> level)
> there are two approaches possible
>
> - communicate over the http session, and ActionLoader
>
> - communicate directly through Java API
Personally I would prefer a Java API. I feel that it makes the code a bit
cleaner, than using a secondary layer (like the session) to communicate data
between objects. Java API also ties in better in the Turbine Services
architecture.
> As I see it now, we would have to have a method Object buildACL(User) in
> the
> UserManager interface, that would delegate to an ACLBuilder interface.
> The security services interfaces would extend ACLBuilder, and the
> UserManager
> (which needs to become a service in it's own right) would have a
> property
> to choose which Turbine service delegate to. We would need to provide
> service
> name, to get an instance of the service. Class name is not enough.
> (I have feeling that the above explainations aren't very clear, but I'm
> feeling
> tired right now - hadn't been sleeping enough in the past few days...
> sorry...)
>
I'm in favour of adding 2 Turbine Services:
- TurbineUserManagerService
- TurbineACLBuilderService
The TurbineUserManagerService does pretty much what the UserManager does
now. It also delegates User.getACL() to the TurbineACLBuilderService ( Or
another service ) that build the security object for the given user.
The ACL is built on the first call to User.getACL() and it is stored for the
duration of the user.
One drawback could be that we are increasingly adding dependencies between
services. It should not be a show stopper because services already depend
on one-another. There is a bit of pain for the docs volunteers :-)
> Yup. I agree. Talking about TurbineJava - I'd be glad to see all the
> stuff from
> Turbine.doGet moved into ServletService, so that logic could be easily
> customizable.
That would be cool, but I think we shouldn't go overboard :-)
> Sure. We can start working on decoupling UserManager/SecurityService and
> User/ACL right now. June is the estimated timeline for our (e-point)
> alternative security/ACL system, designed for intranets/document
> mnagement systems, that we are working on, and are willing to publish.
>
That would be great. It will solve a lot of headache for my security...
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/28/01 1:08 AM, "Rafal Krzewski" <Ra...@e-point.pl> wrote:
> Talking about TurbineJava - I'd be glad to see all the
> stuff from
> Turbine.doGet moved into ServletService, so that logic could be easily
> customizable.
Uh. I'm not so sure about that. The point being that the logic in
Turbine.java doGet() is not intended to be customizable. That is why the
doGet method is marked as final.
If there is a problem in Turbine.java, then it should be fixed, not factored
out and overridden.
If you want to write your own Servlet that does something differently, then
go for it. I don't think that the Turbine framework prevents you from doing
that at all.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Leon Messerschmidt wrote:
>
> > As I see it right, you will have to include the logic that is contained
> > in
> > the Turbine.doGet() (clearing the session) and AccessControler (crating
> > the ACL and stuffing it into the session) into your "secondary login"
> > action. This will get things done, within (well, kind of :-)) the
> > existing
> > framework.
>
> Please don't take this the wrong way, but it sounds like a terrible hack to
> me :-)
:-) I guess so. We need to improve the framework then.
> >
> > 1) The getACL() method in User interface would have to return Object,
> > and
> > the *SecureScreen/*SecureAction would have to cast it explicitly to
> > the
> > access control listc class it uses. I think it's OK because:
> > a) a SecureScreen depends a lot on the specific ACL/SecurityService
> > b) you always override that class, so the casting would be hidden
> > inside
> > the base class
>
> I like this. Even if you a different object than ACL you can still use it
> you only need to create a new SecureNonACLScreen ) and everything works
> fine!
>
> > 2) the getACL() method would have to consult the session for the ACL
> > object.
> > It should be the same session that the User object is bound to. This
> > is
> > easy, we can use valueBound(BindingEvent) method from
> > SessionBindingListener
> > interface.
>
> If we use #3 then it'll probably not be necessary to do stuff on
> valueBound(). We only need to build the ACL once it is asked for the first
> time... Or am I misinterpreting something here?
The binding event we'll receive on valueBound() will give us a reference
to the session object, where we should look for the ACL object.
> > 3) if the ACL is not found in the session, AccessControler is called,
> > and then
> > the session is consulted again. If no ACL object is present, null ACL
> > is
> > returnd to the application . Alternativelny empty (no permissions)
> > ACL could
> > be returned.
>
> Just a thought: We can have a default ACL (non-empty) returned if the
> session is empty. This will allow us to specify permissions for the default
> user.
My approach to this problem is somewhat reversed: In the AccessControler
action, if there is no User in the session, load a real "guest" user
from
the DB instead of anonymous user. This way you can assign permissions to
this user. In this approach, assiging rights to not logged in users
requires modyfing the AccessControler only (which is a plugable
component
by desingn) and not the framework.
> > 4) the ACL should be unbound from the session at the same time the User
> > object
> > is which is possible using the valueUnbound() method, just as John
> > suggested
> > in his reply.
>
> I don't know the internals well enough, but why not use setTemp() for this
> (or alternatively just an instance variable). It would probably require
> that the AccessControler becomes an interface/implementation arhcitecture
> instead of an action. This would do away with the need to do special things
> in valueUnbound.
If our goal is separation of User/user management from the ACL/security
service
(note that the possible security services may differ at the *interface*
level)
there are two approaches possible
- communicate over the http session, and ActionLoader
- communicate directly through Java API
As I see it now, we would have to have a method Object buildACL(User) in
the
UserManager interface, that would delegate to an ACLBuilder interface.
The security services interfaces would extend ACLBuilder, and the
UserManager
(which needs to become a service in it's own right) would have a
property
to choose which Turbine service delegate to. We would need to provide
service
name, to get an instance of the service. Class name is not enough.
(I have feeling that the above explainations aren't very clear, but I'm
feeling
tired right now - hadn't been sleeping enough in the past few days...
sorry...)
> > If we do all of the above, we could remove the getACL() from RunData,
> > and have
> > a realy good basis for a pluggable ACL system. The downside is that will
> > have
> > a good deal of sophisticated logic inside TurbineUser class, and
> > cretating
> > custom replacements for it will become a bit more tricky.
>
> It will take some complexity out of Turbine.java, which is an improvement to
> me.
Yup. I agree. Talking about TurbineJava - I'd be glad to see all the
stuff from
Turbine.doGet moved into ServletService, so that logic could be easily
customizable.
> > (as you may have guessed I'm working on such a system right now. If
> > everything
> > works out well it will be published into Turbine somewere around June)
>
> I'd like to have the ACL stuff in there a bit earlier than that, but I don't
> want do duplicate things, or break your code. Can we coordinate this in
> some way that I can start on a getACL() method for User/TurbineUser?
Sure. We can start working on decoupling UserManager/SecurityService and
User/ACL right now. June is the estimated timeline for our (e-point)
alternative security/ACL system, designed for intranets/document
mnagement systems, that we are working on, and are willing to publish.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Leon Messerschmidt <le...@opticode.co.za>.
> As I see it right, you will have to include the logic that is contained
> in
> the Turbine.doGet() (clearing the session) and AccessControler (crating
> the ACL and stuffing it into the session) into your "secondary login"
> action. This will get things done, within (well, kind of :-)) the
> existing
> framework.
Please don't take this the wrong way, but it sounds like a terrible hack to
me :-)
> > I'm there will be other ways of breaking the current system, because
there
> > is no way of validating that the ACL in the session does in fact belong
to
> > the user that is logged in.
>
> If the code that puts User/ACL into the session is correct, it will work
> fine.
> On the other hand, there is no way of protecting against malicious
> developer...
:-)
> > The ACL gets build the an AccessControler action. If you require an
> > alternative security implementation the best place to add this would be
the
> > AccessControler.
>
> True.
>
> > I don't think your above mentioned idea allows for pluggable
implementations
> > without breaking code. You need to have a standard interface for your
app
> > to query roles/permissions regardless of the backend or security
> > implementation.
>
> You cannot have a standard interface for all possible security systems.
> The
> very definition of "permission" or "group" (yeah, this is a good one)
> varies
> from one security system to another. This would be acceptable form my
> point
> of view the following conditions would have to be met:
>
> 1) The getACL() method in User interface would have to return Object,
> and
> the *SecureScreen/*SecureAction would have to cast it explicitly to
> the
> access control listc class it uses. I think it's OK because:
> a) a SecureScreen depends a lot on the specific ACL/SecurityService
> b) you always override that class, so the casting would be hidden
> inside
> the base class
I like this. Even if you a different object than ACL you can still use it
you only need to create a new SecureNonACLScreen ) and everything works
fine!
> 2) the getACL() method would have to consult the session for the ACL
> object.
> It should be the same session that the User object is bound to. This
> is
> easy, we can use valueBound(BindingEvent) method from
> SessionBindingListener
> interface.
If we use #3 then it'll probably not be necessary to do stuff on
valueBound(). We only need to build the ACL once it is asked for the first
time... Or am I misinterpreting something here?
> 3) if the ACL is not found in the session, AccessControler is called,
> and then
> the session is consulted again. If no ACL object is present, null ACL
> is
> returnd to the application . Alternativelny empty (no permissions)
> ACL could
> be returned.
Just a thought: We can have a default ACL (non-empty) returned if the
session is empty. This will allow us to specify permissions for the default
user.
> 4) the ACL should be unbound from the session at the same time the User
> object
> is which is possible using the valueUnbound() method, just as John
> suggested
> in his reply.
I don't know the internals well enough, but why not use setTemp() for this
(or alternatively just an instance variable). It would probably require
that the AccessControler becomes an interface/implementation arhcitecture
instead of an action. This would do away with the need to do special things
in valueUnbound.
> If we do all of the above, we could remove the getACL() from RunData,
> and have
> a realy good basis for a pluggable ACL system. The downside is that will
> have
> a good deal of sophisticated logic inside TurbineUser class, and
> cretating
> custom replacements for it will become a bit more tricky.
It will take some complexity out of Turbine.java, which is an improvement to
me.
> (as you may have guessed I'm working on such a system right now. If
> everything
> works out well it will be published into Turbine somewere around June)
I'd like to have the ACL stuff in there a bit earlier than that, but I don't
want do duplicate things, or break your code. Can we coordinate this in
some way that I can start on a getACL() method for User/TurbineUser?
> > I think there is more serious problems than just lack of documentation.
>
> The problems could be avoided in the current system, if people were
> aware
> of them. But you are right. Some of them can be solved at the framework
> level without significant performance penalty.
>
> Rafal
>
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Leon Messerschmidt wrote:
> I fixed that but I then realized that I have two actions that will result in
> a login. A normal loginUser action and I automatically login a user when he
> registers with a registerUser action. Setting either in the TR.properties
> results in the other to be able to get an invalid session object.
>
> My colleague stumbled across the same problem in another way. He has a
> fairly complex admin system and he wants to "simulate" a users login to an
> administrator. For this he wrote an action code for changing the user.
> Again this does not go through the default login action and it breaks the
> security system.
Oh. I understand. When your "secondary login" action is executed it
changes
the User object in the session, *after* the access controler
action retrieved checked that the ACL is present, which was the ACL of
the
previous user.
As I see it right, you will have to include the logic that is contained
in
the Turbine.doGet() (clearing the session) and AccessControler (crating
the ACL and stuffing it into the session) into your "secondary login"
action. This will get things done, within (well, kind of :-)) the
existing
framework.
> I'm there will be other ways of breaking the current system, because there
> is no way of validating that the ACL in the session does in fact belong to
> the user that is logged in.
If the code that puts User/ACL into the session is correct, it will work
fine.
On the other hand, there is no way of protecting against malicious
developer...
> > I also don't think that including getACL() method into User interface is
> > a good idea, because I see no reason to couple these two. The ACL object
> > depends on an User object, but the oposite is not true - you can have an
> > User object without ACL, or you can have an alternative access control
> > system, that depends on Turbine User interface.
>
> The ACL gets build the an AccessControler action. If you require an
> alternative security implementation the best place to add this would be the
> AccessControler.
True.
> I don't think your above mentioned idea allows for pluggable implementations
> without breaking code. You need to have a standard interface for your app
> to query roles/permissions regardless of the backend or security
> implementation.
You cannot have a standard interface for all possible security systems.
The
very definition of "permission" or "group" (yeah, this is a good one)
varies
from one security system to another. This would be acceptable form my
point
of view the following conditions would have to be met:
1) The getACL() method in User interface would have to return Object,
and
the *SecureScreen/*SecureAction would have to cast it explicitly to
the
access control listc class it uses. I think it's OK because:
a) a SecureScreen depends a lot on the specific ACL/SecurityService
b) you always override that class, so the casting would be hidden
inside
the base class
2) the getACL() method would have to consult the session for the ACL
object.
It should be the same session that the User object is bound to. This
is
easy, we can use valueBound(BindingEvent) method from
SessionBindingListener
interface.
3) if the ACL is not found in the session, AccessControler is called,
and then
the session is consulted again. If no ACL object is present, null ACL
is
returnd to the application . Alternativelny empty (no permissions)
ACL could
be returned.
4) the ACL should be unbound from the session at the same time the User
object
is which is possible using the valueUnbound() method, just as John
suggested
in his reply.
If we do all of the above, we could remove the getACL() from RunData,
and have
a realy good basis for a pluggable ACL system. The downside is that will
have
a good deal of sophisticated logic inside TurbineUser class, and
cretating
custom replacements for it will become a bit more tricky.
(as you may have guessed I'm working on such a system right now. If
everything
works out well it will be published into Turbine somewere around June)
> I think there is more serious problems than just lack of documentation.
The problems could be avoided in the current system, if people were
aware
of them. But you are right. Some of them can be solved at the framework
level without significant performance penalty.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Leon Messerschmidt <le...@opticode.co.za>.
Hi Rafal,
> > screen is displayed. Clicking back and login _always_ results in a
stale
> > ACL for at least one screen.
>
> The login action is executed before the screen, so the screen will see
> the
> session cleared, or I missing
I fixed that but I then realized that I have two actions that will result in
a login. A normal loginUser action and I automatically login a user when he
registers with a registerUser action. Setting either in the TR.properties
results in the other to be able to get an invalid session object.
My colleague stumbled across the same problem in another way. He has a
fairly complex admin system and he wants to "simulate" a users login to an
administrator. For this he wrote an action code for changing the user.
Again this does not go through the default login action and it breaks the
security system.
I'm there will be other ways of breaking the current system, because there
is no way of validating that the ACL in the session does in fact belong to
the user that is logged in.
> > The solution, as pointed out to me, was to add a getACL() method to the
user
> > interface and to execute the AccessControler from there. This prevents
the
> > state ACL problem form occurring, and it simplifies both code in Turbine
> > (extra code in Turbine.java) and actions written by users (you do not
need
> > to explicitly call data.setACL (null) on login or logout).
>
> This would mean that the ACL will have to be rebuilt on each hit. This
> means
> accessing the database/directory server and additional computations. I'd
> much
> prefer if this information was cached in the user's session for
> performance
> reasons.
It won't need to build on every hit. Something like this work:
(if this.acl == null)
{
// get ACL from AccessController
}
return acl
> I'd say - code your Login/Logout actions right, otherwise you'll get
> wrong
> behaviour. We shouldn't sacrifice performance only to support sloppy
> programing
> at the same time.
>
> I also don't think that including getACL() method into User interface is
> a good idea, because I see no reason to couple these two. The ACL object
> depends on an User object, but the oposite is not true - you can have an
> User object without ACL, or you can have an alternative access control
> system, that depends on Turbine User interface.
The ACL gets build the an AccessControler action. If you require an
alternative security implementation the best place to add this would be the
AccessControler.
I don't think your above mentioned idea allows for pluggable implementations
without breaking code. You need to have a standard interface for your app
to query roles/permissions regardless of the backend or security
implementation.
> > We can mark the data.getACL() method as deprecated and in the mean time
> > simply return data.getUser().getACL(). Eventually everybody should only
be
> > calling data.getUser().getACL().
> >
> > If it is ok with everybody I will volunteer to do this.
>
> Thanks, but I think what we need is better documentation of Login/Logout
> behaviour in the Javadocs, and possibly xdocs too.
I think there is more serious problems than just lack of documentation.
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Security and ACL
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Leon Messerschmidt wrote:
> A colleague pointed out a situation that would happen in places where people
> share computers - like schools & universities. Say a user has logged. A
> second user sees something cool in the app and also wants to log in - he
> presses the back button and enters his details on the login screen.
>
> Because the ACL is stored in the session the second user will end up with
> the ACL of the first, unless you call a data.setACL (null) in the login
> action. Even when calling data.setACL (null) the second user (by looking at
> the order of events in Turbine.java) will have the stale ACL when the first
> screen is displayed. Clicking back and login _always_ results in a stale
> ACL for at least one screen.
The login action is executed before the screen, so the screen will see
the
session cleared, or I missing
> The solution, as pointed out to me, was to add a getACL() method to the user
> interface and to execute the AccessControler from there. This prevents the
> state ACL problem form occurring, and it simplifies both code in Turbine
> (extra code in Turbine.java) and actions written by users (you do not need
> to explicitly call data.setACL (null) on login or logout).
This would mean that the ACL will have to be rebuilt on each hit. This
means
accessing the database/directory server and additional computations. I'd
much
prefer if this information was cached in the user's session for
performance
reasons.
I'd say - code your Login/Logout actions right, otherwise you'll get
wrong
behaviour. We shouldn't sacrifice performance only to support sloppy
programing
at the same time.
I also don't think that including getACL() method into User interface is
a good idea, because I see no reason to couple these two. The ACL object
depends on an User object, but the oposite is not true - you can have an
User object without ACL, or you can have an alternative access control
system, that depends on Turbine User interface.
> We can mark the data.getACL() method as deprecated and in the mean time
> simply return data.getUser().getACL(). Eventually everybody should only be
> calling data.getUser().getACL().
>
> If it is ok with everybody I will volunteer to do this.
Thanks, but I think what we need is better documentation of Login/Logout
behaviour in the Javadocs, and possibly xdocs too.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org