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. > > >
