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
