You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Kalle Korhonen <ka...@gmail.com> on 2009/02/23 06:31:24 UTC
Refactoring WebConfiguration & IniWebConfiguration
Below is an excerpt of my previous email to the user list on the motivation
for refactoring WebConfiguration & IniWebConfiguration. To better support
configuring JSecurity in all-Java (without ini files that is), I'd like to
add super, possibly abstract implementation of WebConfiguration that
IniWebConfiguration would inherit from (rather than simply extend the
interface). Also, I'd like to add SecurityFilterChain class to carry
path-specific filter config information that this base implmentation of
WebConfiguration would use. The refactoring would roughly follow the
prototype implementation I made for Trails project (
http://www.trailsframework.org) for integration with jsecurity, see
http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand
http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java.
I'd need to touch several classes but I'd keep the public interfaces the
same if at all possible. Does anybody see issue with what I'm proposing, and
if not, should I just add it in one single JIRA and patch (and hopefully get
somebody to look over it)? I could of course make several patches and
refactor it little by litte, but I'm afraid it'd difficult to see the goal
if the changes are broken into several patches. What say you?
Kalle
On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:
> Hello jsecurity devs,
>
> I'm working on an initial integration of jsecurity with Tapestry5 as a
> proof of concept. I'm especially keen on your flexible, built-in support for
> instance-based security. With a considerable amount of hammering, I
> implemented instance-based security for previous version of Trails framework
> (which I'm a committer of) using Acegi (see for example
> http://trailsframework.org/Security+module) and now I'm back for more :).
> I've been an Acegi/Spring user for years but in an effort to reduce the
> clutter and the "weight of history", I'm trying to remove dependencies to
> them. Also, Acegi committers are very reluctant to change the existing
> implementation even when it would make perfect sense (e.g.
> http://jira.springframework.org/browse/SEC-517). As a first cut, I've
> implemented basic url-based configuration and permission for Tapestry5 using
> JSecurity. However, it wasn't quite as simple as I would have hoped for.
> From my perspective, a little bit of refactoring would make your framework
> better suited for many different cases. For instance it'd be so much nicer
> if IniWebConfiguration would use composition for the ini files rather rather
> than inheritance. Right now, I either need to inherit from
> IniWebConfiguration (my Tapestry integration doesn't use the ini) and accept
> lots of unnecessary operations or copy and paste several operations.
> Similarly, it'd be much nicer if you custom types such as
> SecurityFilterChain rather List<Filter> so it's extensible and can carry
> more information (such as path-specific filter config). Finally, there's a
> few places where you are doing new Object() & setObject() within the same
> operation, again making it more difficult to extend the framework and
> specifically for applying dependency injection. I'm not suggesting any
> changes specifically for Tapestry integration.
>
Re: Refactoring WebConfiguration & IniWebConfiguration
Posted by Kalle Korhonen <ka...@gmail.com>.
On Thu, Feb 26, 2009 at 11:11 AM, Les Hazlewood <lh...@apache.org>wrote:
> Ah, I see now - the SecurityFilterChain is probably what I would call a
> SecurityFilterLink or SecurityChainLink or SecurityFilterChainLink or
> something like that - it isn't a chain really, but a link or element in the
> chain - right?
No, it is a chain. In the previous version it was more explicit as it
accepted a list of filters as a parameter. The Handler is a facade to a
filter chain... I don't know how much more clear this'll make it but you can
take a look at the factory implementation:
http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChainFactoryImpl.java.
This is what I mean by built-in support for building pipelines, you'll see
it in action there (but might be a bit difficult to understand it without
diving more deeply into Tapestry). To tie this back into possible
enhancements to JSecurity, we could have a generic SecurityFilterChain
interface that accepts a list of filters (list of objects?) and then the
Tapestry-specific implementation would use the factory internally. But just
have to see how it goes - I'm probably not done with refactoring yet.
> Interesting that you had to re-implement the JSecurityFilter because of
> Tapestry's architecture. I don't know anything about how they handle
> chaining, but lemme know if you think of any adjustments to JSecurityFilter
> that might make things easier to work in Tapestry or other environments.
Well, the main thing is that the whole Tapestry bootstrap is implemented as
a filter; sure you can use other normal filters in front of the Tapestry
filter, but then you don't have access to the Tapestry infrastructure. For
path-based security configuration it barely matters, but if you want to do
something more interesting, such as protecting the operation invocations it
does. For example, see what the the tapestry-spring-security integration
modules does (
http://www.localhost.nu/java/tapestry-spring-security/usage.html). And of
course, by making the jsecurity filter Tapestry-specific you can utilize
"distributed configuration", basically each library can add configuration to
existing modules that are expected to be available.
Kalle
> On Thu, Feb 26, 2009 at 1:42 PM, Kalle Korhonen
> <ka...@gmail.com>wrote:
>
> > No sorry, nothing wrong with Codehaus' infratstructure, this is my fault.
> > Since I'm moving rather fast, I already renamed the project. The fixed
> link
> > to SecurityFilterChain is
> >
> >
> http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> > ,
> > but in the latest incarnation I made it Tapestry specific. Tapestry has
> > built-in support for pipeline pattern, so after I re-factored
> > JSecurityFilter as Tapestry-specific (
> >
> >
> http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/JSecurityConfiguration.java
> > )
> > I was able to eliminate lots of unnecessary code.
> >
> > I think there's value in what I proposed but I have to let my
> > proof-of-concept implementation settle a bit before I can make more
> > coherent
> > improvement suggestions in the form of new jiras and patches. It should
> be
> > relatively easy to refactor those classes as suggested, but given that I
> > wouldn't be using them (I obsoleted the whole configuration since it was
> > highly geared towards ini files), it might make sense to just see what
> > it'll
> > all evolve to.
> >
> > Kalle
> >
> >
> > On Thu, Feb 26, 2009 at 10:08 AM, Les Hazlewood <lhazlewood@apache.org
> > >wrote:
> >
> > > Hi Kalle,
> > >
> > > Both of the svn links below give me a 404 Not Found (yes, I corrected
> the
> > > 'and' at the end of the first link).
> > >
> > > I like the idea of a SecurityFilterChain and as we said before, it'd be
> > > nice
> > > to move away from inheritance for configuration and instead move to a
> > > composition model.
> > >
> > > I'm looking forward to seeing your ideas - dunno if there is something
> > > wrong
> > > with the codehaus http browsing of svn at the moment or not :/
> > >
> > > - Les
> > >
> > > On Mon, Feb 23, 2009 at 12:31 AM, Kalle Korhonen <
> > > kalle.o.korhonen@gmail.com
> > > > wrote:
> > >
> > > > Below is an excerpt of my previous email to the user list on the
> > > motivation
> > > > for refactoring WebConfiguration & IniWebConfiguration. To better
> > support
> > > > configuring JSecurity in all-Java (without ini files that is), I'd
> like
> > > to
> > > > add super, possibly abstract implementation of WebConfiguration that
> > > > IniWebConfiguration would inherit from (rather than simply extend the
> > > > interface). Also, I'd like to add SecurityFilterChain class to carry
> > > > path-specific filter config information that this base implmentation
> of
> > > > WebConfiguration would use. The refactoring would roughly follow the
> > > > prototype implementation I made for Trails project (
> > > > http://www.trailsframework.org) for integration with jsecurity, see
> > > >
> > > >
> > >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand
> > > >
> > > >
> > >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> > > > .
> > > > I'd need to touch several classes but I'd keep the public interfaces
> > the
> > > > same if at all possible. Does anybody see issue with what I'm
> > proposing,
> > > > and
> > > > if not, should I just add it in one single JIRA and patch (and
> > hopefully
> > > > get
> > > > somebody to look over it)? I could of course make several patches and
> > > > refactor it little by litte, but I'm afraid it'd difficult to see the
> > > goal
> > > > if the changes are broken into several patches. What say you?
> > > >
> > > > Kalle
> > > >
> > > >
> > > > On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <
> > > > kalle.o.korhonen@gmail.com
> > > > > wrote:
> > > >
> > > > > Hello jsecurity devs,
> > > > >
> > > > > I'm working on an initial integration of jsecurity with Tapestry5
> as
> > a
> > > > > proof of concept. I'm especially keen on your flexible, built-in
> > > support
> > > > for
> > > > > instance-based security. With a considerable amount of hammering, I
> > > > > implemented instance-based security for previous version of Trails
> > > > framework
> > > > > (which I'm a committer of) using Acegi (see for example
> > > > > http://trailsframework.org/Security+module) and now I'm back for
> > more
> > > > :).
> > > > > I've been an Acegi/Spring user for years but in an effort to reduce
> > the
> > > > > clutter and the "weight of history", I'm trying to remove
> > dependencies
> > > to
> > > > > them. Also, Acegi committers are very reluctant to change the
> > existing
> > > > > implementation even when it would make perfect sense (e.g.
> > > > > http://jira.springframework.org/browse/SEC-517). As a first cut,
> > I've
> > > > > implemented basic url-based configuration and permission for
> > Tapestry5
> > > > using
> > > > > JSecurity. However, it wasn't quite as simple as I would have hoped
> > > for.
> > > > > From my perspective, a little bit of refactoring would make your
> > > > framework
> > > > > better suited for many different cases. For instance it'd be so
> much
> > > > nicer
> > > > > if IniWebConfiguration would use composition for the ini files
> rather
> > > > rather
> > > > > than inheritance. Right now, I either need to inherit from
> > > > > IniWebConfiguration (my Tapestry integration doesn't use the ini)
> and
> > > > accept
> > > > > lots of unnecessary operations or copy and paste several
> operations.
> > > > > Similarly, it'd be much nicer if you custom types such as
> > > > > SecurityFilterChain rather List<Filter> so it's extensible and can
> > > carry
> > > > > more information (such as path-specific filter config). Finally,
> > > there's
> > > > a
> > > > > few places where you are doing new Object() & setObject() within
> the
> > > same
> > > > > operation, again making it more difficult to extend the framework
> and
> > > > > specifically for applying dependency injection. I'm not suggesting
> > any
> > > > > changes specifically for Tapestry integration.
> > > > >
> > > >
> > >
> >
>
Re: Refactoring WebConfiguration & IniWebConfiguration
Posted by Les Hazlewood <lh...@apache.org>.
Ah, I see now - the SecurityFilterChain is probably what I would call a
SecurityFilterLink or SecurityChainLink or SecurityFilterChainLink or
something like that - it isn't a chain really, but a link or element in the
chain - right?
Interesting that you had to re-implement the JSecurityFilter because of
Tapestry's architecture. I don't know anything about how they handle
chaining, but lemme know if you think of any adjustments to JSecurityFilter
that might make things easier to work in Tapestry or other environments.
Cheers,
Les
On Thu, Feb 26, 2009 at 1:42 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> No sorry, nothing wrong with Codehaus' infratstructure, this is my fault.
> Since I'm moving rather fast, I already renamed the project. The fixed link
> to SecurityFilterChain is
>
> http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> ,
> but in the latest incarnation I made it Tapestry specific. Tapestry has
> built-in support for pipeline pattern, so after I re-factored
> JSecurityFilter as Tapestry-specific (
>
> http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/JSecurityConfiguration.java
> )
> I was able to eliminate lots of unnecessary code.
>
> I think there's value in what I proposed but I have to let my
> proof-of-concept implementation settle a bit before I can make more
> coherent
> improvement suggestions in the form of new jiras and patches. It should be
> relatively easy to refactor those classes as suggested, but given that I
> wouldn't be using them (I obsoleted the whole configuration since it was
> highly geared towards ini files), it might make sense to just see what
> it'll
> all evolve to.
>
> Kalle
>
>
> On Thu, Feb 26, 2009 at 10:08 AM, Les Hazlewood <lhazlewood@apache.org
> >wrote:
>
> > Hi Kalle,
> >
> > Both of the svn links below give me a 404 Not Found (yes, I corrected the
> > 'and' at the end of the first link).
> >
> > I like the idea of a SecurityFilterChain and as we said before, it'd be
> > nice
> > to move away from inheritance for configuration and instead move to a
> > composition model.
> >
> > I'm looking forward to seeing your ideas - dunno if there is something
> > wrong
> > with the codehaus http browsing of svn at the moment or not :/
> >
> > - Les
> >
> > On Mon, Feb 23, 2009 at 12:31 AM, Kalle Korhonen <
> > kalle.o.korhonen@gmail.com
> > > wrote:
> >
> > > Below is an excerpt of my previous email to the user list on the
> > motivation
> > > for refactoring WebConfiguration & IniWebConfiguration. To better
> support
> > > configuring JSecurity in all-Java (without ini files that is), I'd like
> > to
> > > add super, possibly abstract implementation of WebConfiguration that
> > > IniWebConfiguration would inherit from (rather than simply extend the
> > > interface). Also, I'd like to add SecurityFilterChain class to carry
> > > path-specific filter config information that this base implmentation of
> > > WebConfiguration would use. The refactoring would roughly follow the
> > > prototype implementation I made for Trails project (
> > > http://www.trailsframework.org) for integration with jsecurity, see
> > >
> > >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand
> > >
> > >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> > > .
> > > I'd need to touch several classes but I'd keep the public interfaces
> the
> > > same if at all possible. Does anybody see issue with what I'm
> proposing,
> > > and
> > > if not, should I just add it in one single JIRA and patch (and
> hopefully
> > > get
> > > somebody to look over it)? I could of course make several patches and
> > > refactor it little by litte, but I'm afraid it'd difficult to see the
> > goal
> > > if the changes are broken into several patches. What say you?
> > >
> > > Kalle
> > >
> > >
> > > On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <
> > > kalle.o.korhonen@gmail.com
> > > > wrote:
> > >
> > > > Hello jsecurity devs,
> > > >
> > > > I'm working on an initial integration of jsecurity with Tapestry5 as
> a
> > > > proof of concept. I'm especially keen on your flexible, built-in
> > support
> > > for
> > > > instance-based security. With a considerable amount of hammering, I
> > > > implemented instance-based security for previous version of Trails
> > > framework
> > > > (which I'm a committer of) using Acegi (see for example
> > > > http://trailsframework.org/Security+module) and now I'm back for
> more
> > > :).
> > > > I've been an Acegi/Spring user for years but in an effort to reduce
> the
> > > > clutter and the "weight of history", I'm trying to remove
> dependencies
> > to
> > > > them. Also, Acegi committers are very reluctant to change the
> existing
> > > > implementation even when it would make perfect sense (e.g.
> > > > http://jira.springframework.org/browse/SEC-517). As a first cut,
> I've
> > > > implemented basic url-based configuration and permission for
> Tapestry5
> > > using
> > > > JSecurity. However, it wasn't quite as simple as I would have hoped
> > for.
> > > > From my perspective, a little bit of refactoring would make your
> > > framework
> > > > better suited for many different cases. For instance it'd be so much
> > > nicer
> > > > if IniWebConfiguration would use composition for the ini files rather
> > > rather
> > > > than inheritance. Right now, I either need to inherit from
> > > > IniWebConfiguration (my Tapestry integration doesn't use the ini) and
> > > accept
> > > > lots of unnecessary operations or copy and paste several operations.
> > > > Similarly, it'd be much nicer if you custom types such as
> > > > SecurityFilterChain rather List<Filter> so it's extensible and can
> > carry
> > > > more information (such as path-specific filter config). Finally,
> > there's
> > > a
> > > > few places where you are doing new Object() & setObject() within the
> > same
> > > > operation, again making it more difficult to extend the framework and
> > > > specifically for applying dependency injection. I'm not suggesting
> any
> > > > changes specifically for Tapestry integration.
> > > >
> > >
> >
>
Re: Refactoring WebConfiguration & IniWebConfiguration
Posted by Kalle Korhonen <ka...@gmail.com>.
No sorry, nothing wrong with Codehaus' infratstructure, this is my fault.
Since I'm moving rather fast, I already renamed the project. The fixed link
to SecurityFilterChain is
http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java,
but in the latest incarnation I made it Tapestry specific. Tapestry has
built-in support for pipeline pattern, so after I re-factored
JSecurityFilter as Tapestry-specific (
http://svn.codehaus.org/trails/trunk/tapestry-jsecurity/src/main/java/org/trailsframework/security/services/JSecurityConfiguration.java)
I was able to eliminate lots of unnecessary code.
I think there's value in what I proposed but I have to let my
proof-of-concept implementation settle a bit before I can make more coherent
improvement suggestions in the form of new jiras and patches. It should be
relatively easy to refactor those classes as suggested, but given that I
wouldn't be using them (I obsoleted the whole configuration since it was
highly geared towards ini files), it might make sense to just see what it'll
all evolve to.
Kalle
On Thu, Feb 26, 2009 at 10:08 AM, Les Hazlewood <lh...@apache.org>wrote:
> Hi Kalle,
>
> Both of the svn links below give me a 404 Not Found (yes, I corrected the
> 'and' at the end of the first link).
>
> I like the idea of a SecurityFilterChain and as we said before, it'd be
> nice
> to move away from inheritance for configuration and instead move to a
> composition model.
>
> I'm looking forward to seeing your ideas - dunno if there is something
> wrong
> with the codehaus http browsing of svn at the moment or not :/
>
> - Les
>
> On Mon, Feb 23, 2009 at 12:31 AM, Kalle Korhonen <
> kalle.o.korhonen@gmail.com
> > wrote:
>
> > Below is an excerpt of my previous email to the user list on the
> motivation
> > for refactoring WebConfiguration & IniWebConfiguration. To better support
> > configuring JSecurity in all-Java (without ini files that is), I'd like
> to
> > add super, possibly abstract implementation of WebConfiguration that
> > IniWebConfiguration would inherit from (rather than simply extend the
> > interface). Also, I'd like to add SecurityFilterChain class to carry
> > path-specific filter config information that this base implmentation of
> > WebConfiguration would use. The refactoring would roughly follow the
> > prototype implementation I made for Trails project (
> > http://www.trailsframework.org) for integration with jsecurity, see
> >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand
> >
> >
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> > .
> > I'd need to touch several classes but I'd keep the public interfaces the
> > same if at all possible. Does anybody see issue with what I'm proposing,
> > and
> > if not, should I just add it in one single JIRA and patch (and hopefully
> > get
> > somebody to look over it)? I could of course make several patches and
> > refactor it little by litte, but I'm afraid it'd difficult to see the
> goal
> > if the changes are broken into several patches. What say you?
> >
> > Kalle
> >
> >
> > On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <
> > kalle.o.korhonen@gmail.com
> > > wrote:
> >
> > > Hello jsecurity devs,
> > >
> > > I'm working on an initial integration of jsecurity with Tapestry5 as a
> > > proof of concept. I'm especially keen on your flexible, built-in
> support
> > for
> > > instance-based security. With a considerable amount of hammering, I
> > > implemented instance-based security for previous version of Trails
> > framework
> > > (which I'm a committer of) using Acegi (see for example
> > > http://trailsframework.org/Security+module) and now I'm back for more
> > :).
> > > I've been an Acegi/Spring user for years but in an effort to reduce the
> > > clutter and the "weight of history", I'm trying to remove dependencies
> to
> > > them. Also, Acegi committers are very reluctant to change the existing
> > > implementation even when it would make perfect sense (e.g.
> > > http://jira.springframework.org/browse/SEC-517). As a first cut, I've
> > > implemented basic url-based configuration and permission for Tapestry5
> > using
> > > JSecurity. However, it wasn't quite as simple as I would have hoped
> for.
> > > From my perspective, a little bit of refactoring would make your
> > framework
> > > better suited for many different cases. For instance it'd be so much
> > nicer
> > > if IniWebConfiguration would use composition for the ini files rather
> > rather
> > > than inheritance. Right now, I either need to inherit from
> > > IniWebConfiguration (my Tapestry integration doesn't use the ini) and
> > accept
> > > lots of unnecessary operations or copy and paste several operations.
> > > Similarly, it'd be much nicer if you custom types such as
> > > SecurityFilterChain rather List<Filter> so it's extensible and can
> carry
> > > more information (such as path-specific filter config). Finally,
> there's
> > a
> > > few places where you are doing new Object() & setObject() within the
> same
> > > operation, again making it more difficult to extend the framework and
> > > specifically for applying dependency injection. I'm not suggesting any
> > > changes specifically for Tapestry integration.
> > >
> >
>
Re: Refactoring WebConfiguration & IniWebConfiguration
Posted by Les Hazlewood <lh...@apache.org>.
Hi Kalle,
Both of the svn links below give me a 404 Not Found (yes, I corrected the
'and' at the end of the first link).
I like the idea of a SecurityFilterChain and as we said before, it'd be nice
to move away from inheritance for configuration and instead move to a
composition model.
I'm looking forward to seeing your ideas - dunno if there is something wrong
with the codehaus http browsing of svn at the moment or not :/
- Les
On Mon, Feb 23, 2009 at 12:31 AM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:
> Below is an excerpt of my previous email to the user list on the motivation
> for refactoring WebConfiguration & IniWebConfiguration. To better support
> configuring JSecurity in all-Java (without ini files that is), I'd like to
> add super, possibly abstract implementation of WebConfiguration that
> IniWebConfiguration would inherit from (rather than simply extend the
> interface). Also, I'd like to add SecurityFilterChain class to carry
> path-specific filter config information that this base implmentation of
> WebConfiguration would use. The refactoring would roughly follow the
> prototype implementation I made for Trails project (
> http://www.trailsframework.org) for integration with jsecurity, see
>
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityConfigurationImpl.javaand
>
> http://svn.codehaus.org/trails/trunk/trails-jsecurity/src/main/java/org/trailsframework/security/services/SecurityFilterChain.java
> .
> I'd need to touch several classes but I'd keep the public interfaces the
> same if at all possible. Does anybody see issue with what I'm proposing,
> and
> if not, should I just add it in one single JIRA and patch (and hopefully
> get
> somebody to look over it)? I could of course make several patches and
> refactor it little by litte, but I'm afraid it'd difficult to see the goal
> if the changes are broken into several patches. What say you?
>
> Kalle
>
>
> On Tue, Feb 17, 2009 at 11:03 AM, Kalle Korhonen <
> kalle.o.korhonen@gmail.com
> > wrote:
>
> > Hello jsecurity devs,
> >
> > I'm working on an initial integration of jsecurity with Tapestry5 as a
> > proof of concept. I'm especially keen on your flexible, built-in support
> for
> > instance-based security. With a considerable amount of hammering, I
> > implemented instance-based security for previous version of Trails
> framework
> > (which I'm a committer of) using Acegi (see for example
> > http://trailsframework.org/Security+module) and now I'm back for more
> :).
> > I've been an Acegi/Spring user for years but in an effort to reduce the
> > clutter and the "weight of history", I'm trying to remove dependencies to
> > them. Also, Acegi committers are very reluctant to change the existing
> > implementation even when it would make perfect sense (e.g.
> > http://jira.springframework.org/browse/SEC-517). As a first cut, I've
> > implemented basic url-based configuration and permission for Tapestry5
> using
> > JSecurity. However, it wasn't quite as simple as I would have hoped for.
> > From my perspective, a little bit of refactoring would make your
> framework
> > better suited for many different cases. For instance it'd be so much
> nicer
> > if IniWebConfiguration would use composition for the ini files rather
> rather
> > than inheritance. Right now, I either need to inherit from
> > IniWebConfiguration (my Tapestry integration doesn't use the ini) and
> accept
> > lots of unnecessary operations or copy and paste several operations.
> > Similarly, it'd be much nicer if you custom types such as
> > SecurityFilterChain rather List<Filter> so it's extensible and can carry
> > more information (such as path-specific filter config). Finally, there's
> a
> > few places where you are doing new Object() & setObject() within the same
> > operation, again making it more difficult to extend the framework and
> > specifically for applying dependency injection. I'm not suggesting any
> > changes specifically for Tapestry integration.
> >
>