On Thu, Feb 26, 2009 at 11:11 AM, Les Hazlewood <[email protected]>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 > <[email protected]>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 <[email protected] > > >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 < > > > [email protected] > > > > 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 < > > > > [email protected] > > > > > 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. > > > > > > > > > > > > > > >
