Thanks Kalle and Pierce for your feedback, it's interesting to read a little more about other experiences. I can completely understand the login form issue, something I stopped considering after a short period of time. The tynamo project has some really interesting projects and it seems security is offering me the best combination of tools for what I'm trying to achieve. For now I'll be using a workaround to achieve what I'm doing. Though deadline is approaching quickly, I am considering switching security implementation before go live.

What would you estimate is the amount of work required to implement Shiro Security if current setup uses Spring Security?

Best regards
Daniel

Am 31.07.2010 00:39, schrieb Pierce Wetter:
   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



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to