I followed a similar path. I started trying to use tapestry-spring-security, couldn't figure out how to customize the login form, and switch to Kalle's tapestry-security project, and I'm now a happy customer, and I ended up contributing back to the tapestry-security project some components.
Pierce > I'm completely biased of course so feel free to disregard, but: I used > to be a long time user of Acegi Security (now Spring Security) but > finally got fed up with the peculiarities of the framework and the > inherent inflexibility for supporting some of the more elaborate > security models. I looked around for an alternative and found > JSecurity (now Apache Shiro) and later ended up as a Shiro committer. > Both frameworks will do a decent job if you just need role/type and/or > url-based security, but if you need extensibility, rolling tokens, > dynamic/instance permissions, external authentication sources etc. > Shiro is the better bet. As a co-founder of Tynamo project, it was > natural we would offer security integration with Shiro (which is > largely based Valentin Yerastov's original work on tapestry-jsecurity > integration). I'm also willing to bet that Shiro & tapestry-security > combination will evolve faster than Spring > Security/tapestry-spring-security going forward. > > Kalle > > > On Fri, Jul 30, 2010 at 5:07 AM, Daniel Henze <dhe...@googlemail.com> wrote: >> Well, I did have a glance at it the time I was looking for a security >> solution. But to me it appeared the easiest to go with >> tapestry-spring-security, mainly due to the ease of initial integration. The >> documentation of tynamos tapestry-seems to be quite good as well. From >> looking at the examples page, I'd either have to create a new Realm for >> security check against my database or simply add another Filter. I'll have >> a look at their test suite today to get to know it a little better. >> >> I could not really find a comparison of the different security enhancements >> for Tapestry, so out of curiousity: What are your experiences with Security >> Frameworks, which implementation are you using? >> >> Cheers >> Daniel >> >> Am 30.07.2010 13:30, schrieb Christophe Cordenier: >>> >>> Hi >>> >>> Have you looked in to tynamo security project ? >>> >>> 2010/7/30 Daniel Henze<dhe...@googlemail.com> >>> >>> >>>> >>>> Hi Christophe, >>>> >>>> yes, I have read that article before, but admit that I could not grasp >>>> all >>>> the details by that time and therefore decided to go with >>>> tapestry-spring-security. A lot of knowledge has been gained in between >>>> though, so I will re-read and think about option 3 (re-implementing >>>> security >>>> with my own requirements). This will take a tad longer, but probably >>>> benefit >>>> a lot in terms of learning curve. >>>> >>>> Cheers >>>> Daniel >>>> >>>> Am 30.07.2010 12:34, schrieb Christophe Cordenier: >>>> >>>> Hi >>>> >>>>> >>>>> Have already read this article [1] from Howard, it explains how to >>>>> secure >>>>> an >>>>> application via Annotations and shows the pipeline as well >>>>> >>>>> >>>>> [1] >>>>> >>>>> http://tapestryjava.blogspot.com/2009/12/securing-tapestry-pages-with.html >>>>> >>>>> 2010/7/30 Daniel Henze<dhe...@googlemail.com> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I created a Service, contributeded it as Dispatcher to check on request >>>>>> of >>>>>> secured pages (using tapestry-spring-security with @Secured annotation) >>>>>> whether the user profile has all required fields filled out. In case, >>>>>> information is missing, the user is forwarded to his profile page and >>>>>> requested to update the required fields. >>>>>> >>>>>> So far so good, following the AccessController example from the >>>>>> Tapestry >>>>>> HowTos I could build the service and add it to the Dispatcher Pipeline: >>>>>> --- (important part from AccessController): >>>>>> Component page = componentSource.getPage(pageName); >>>>>> boolean privatePage = page.getClass().getAnnotation( Secured.class ) >>>>>> != >>>>>> null; >>>>>> >>>>>> if (privatePage) >>>>>> { >>>>>> canAccess = false; >>>>>> /* Is the user already authentified ? */ >>>>>> if(asm.exists(User.class)) >>>>>> { >>>>>> User user = asm.get(User.class); >>>>>> canAccess = user.getUserProfile().isComplete(); >>>>>> System.out.println("user " + user.getUsername() + " has >>>>>> completed >>>>>> his profile: " + canAccess); >>>>>> } >>>>>> } >>>>>> --- >>>>>> public static void >>>>>> contributeMasterDispatcher(OrderedConfiguration<Dispatcher> >>>>>> configuration, >>>>>> AccessController accessController){ >>>>>> configuration.add("AccessWithCompleteProfileController", >>>>>> accessController, "after:*"); >>>>>> } >>>>>> --- >>>>>> >>>>>> My problem is apparently with the sequence of the pipeline, as with >>>>>> the >>>>>> above stated "after:*" the service never is actually executed (simple >>>>>> System >>>>>> out calls to check), with "before:*" I get an redirect error from the >>>>>> server >>>>>> ("indefinite loop") and without any declaration it again is not called >>>>>> at >>>>>> all. >>>>>> >>>>>> I'd appreciate a little guidance on the correct way to solve that >>>>>> issue. >>>>>> I >>>>>> see the following options: >>>>>> 1. Get AccessController invoked as the last service in Dispatcher >>>>>> pipeline >>>>>> (all other checks done before). I suspect SecurityChecker to break the >>>>>> line. >>>>>> 2. Figure out whether User is logged in already and do not break the >>>>>> chain >>>>>> in AccessController if User is not logged in. Next page request will do >>>>>> the >>>>>> check. >>>>>> 3. Implement my own Security Checker and include the AccessController >>>>>> into >>>>>> that code. >>>>>> >>>>>> Regards >>>>>> Daniel >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
smime.p7s
Description: S/MIME cryptographic signature