Chris, Thanks for the interesting feedback. I agree that with whatever authentication system, you will need to have some sort of way to tell which pages need to be secured etc. However, what I was trying to say is using the dispatcher approach, I will have to do a lot more work to get there. Let me be more specific:
1. Acegi-spring - Everything is pretty much there for me. I just need to learn how to set it up and configure it. I also like the fact that it is pattern based - meaning I could use 5 lines of specification and the whole app is secured even if I add additional pages later on. 2. Dispatcher approach - Great idea but I will have to come up with a way to set up the "matrix", where to put it (database, LDAP), and write code to read from it. For me personally, why do all that work when a great framework is already out there to do the job? For others, this may be the best approach if they have specific business or technical requirements. 3. Annotate the page classes - I think this is a bad idea because you have to make sure every single page is properly annotated, assuming you are annotating the page to tell what type of security level it requires. If the web app has like 200 web pages, good luck... 4. onActivate - Yes, not a good idea either and I am not implementing full-blown security here. I was just adding a simple check to see if the user needs to login, and you are probably right, it shouldn't belong in the page class. In fact, I can rip it out in my app (because acegi takes care of this), but haven't make a commitment to do it yet :-). In any case, thanks for the feedback. I don't totally agree with everything you say but it makes me think more about if I actually should do things a certain way. Ben -----Original Message----- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2008 10:04 PM To: Tapestry users Subject: Re: Trying to Implement RedirectException in Tapestry 5 Ben Wong wrote: > I decided against the dispatcher approach for the reasons ville.virtanen > brought up. The dispatcher will have to know what pages are secured and > which aren't. > > Whatever authentication system you use will be burdened with the same issue. After all it is a critical variable in the equation. If you use bland acegi/spring-security, than you manage it's knowledge via web.xml or whatever backend. If you use tapestry-acegi or similar methods, you must annotate the page classes. If you use dispatchers/filters, then they must consult a service that understands the permissions matrix. If you use onActivate in any form for access control, you are accomplishing the task in probably the worst possible manner. If your app is small then the consequences may be negligible and the simplicity of implementation on only a few pages /may/ pay off. Imo it should be avoided because the maintenance costs grow steadily with the number of pages needing security. I'm also a critic of inheritance, and doubly so when it's used expressly for inheriting behavior. There are semantic consequences in doing this when it comes to your app's architecture - your page /is-a/ page and in most cases your Customer page won't /be-a/ SecuredPage. Yes the page is secured, but you're describing restrictions imposed on the page by business rules, and generally nothing about its semantic meaning as a Customer page. It specifies how a different layer - the access control layer - should treat the page, but nothing of the page itself. I realize some may view this as walking a rather fine line between pragmatism and theoretical banter, but surely we can all can attest to the values of a shallow class hierarchy. * steps down from soap box * -- http://thegodcode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
