Re: [T5] Restricting Page Access
That's really cool and very useful! To clarify my understanding - how does it deal with protecting links/functions. For example, assume I'm a regular, non-admin user and access the application. Since I'm not an admin, I don't see the link to the Clear database function, but somehow, I can guess it's link. How does the framework protect me from invoking that link anyways? Do you have equivalent functions as ifLoggedIn and ifRole in the java class files? Cheers Erik On 8/27/07, Robin Helgelin [EMAIL PROTECTED] wrote: On 8/27/07, Erik Vullings [EMAIL PROTECTED] wrote: Hi, Just wondering - when dealing with page authorizations, does this model expand to component authorizations, i.e. you may visit the page, but not certain components (redirect to another component), or you can see a component, but with less privileges (e.g. view but not edit). In other words, how would you deal with CRUD (create, read, update, delete) role-based authorization on a component level? I'd say it's up to the component. I've just added two new components in tapestry5-acegi, called IfLoggedIn and IfRole, which can be used in components such as: t:security.ifloggedin You are logged in, welcome! t:security.ifrole role=ROLE_ADMIN You are even logged as admin, cool! t:parameter name=else Sorry, you don't have admin credentials. /t:parameter /t:security.ifrole a t:type=actionlink t:id=logoutLogout/a t:parameter name=else Not logged in, please t:pagelink t:page=LoginPagedo/t:pagelink. /t:parameter /t:security.ifloggedin -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/28/07, Erik Vullings [EMAIL PROTECTED] wrote: To clarify my understanding - how does it deal with protecting links/functions. For example, assume I'm a regular, non-admin user and access the application. Since I'm not an admin, I don't see the link to the Clear database function, but somehow, I can guess it's link. How does the framework protect me from invoking that link anyways? Do you have equivalent functions as ifLoggedIn and ifRole in the java class files? Yes, just use the @Secured(ROLE_ADMIN) annotation on the page class and the framework takes care of the rest. -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/26/07, Charles Mason [EMAIL PROTECTED] wrote: I have made my own worker class, annotation and service. I understand the acegi worker class except for the transform page part. I can't work out how its managing to change the page. Its clearly modifying a method but, I cant really work out how. It's the method transformPage() that actually changes the page. It's that last call to extendMethod(), that actually adds the call to the class. It attaches the class begin render and cleanup render. Acegi double checks things in cleanup whereas you might not need the extra fields injected earlier in that method. The other thing I was struggling with is, how I actually integrate the worker in to my service. I have a RequestFilter working from AppModule which is executed for every request. But how do I use the worker class I have just created? I could just call the transform method, but where do I get the ClassTransformation object from. I assume there is some correct way to apply a ComponentClassTransformWorker to a component Yes, just contribute to the class transform worker, like this, and Tapestry will take care of running it on your classes. public static void contributeComponentClassTransformWorker( OrderedConfigurationComponentClassTransformWorker configuration, SecurityChecker securityChecker) { configuration.add(Acegi, new AcegiWorker(securityChecker)); } -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
Hi, Just wondering - when dealing with page authorizations, does this model expand to component authorizations, i.e. you may visit the page, but not certain components (redirect to another component), or you can see a component, but with less privileges (e.g. view but not edit). In other words, how would you deal with CRUD (create, read, update, delete) role-based authorization on a component level? Cheers Erik On 8/27/07, Robin Helgelin [EMAIL PROTECTED] wrote: On 8/26/07, Charles Mason [EMAIL PROTECTED] wrote: I have made my own worker class, annotation and service. I understand the acegi worker class except for the transform page part. I can't work out how its managing to change the page. Its clearly modifying a method but, I cant really work out how. It's the method transformPage() that actually changes the page. It's that last call to extendMethod(), that actually adds the call to the class. It attaches the class begin render and cleanup render. Acegi double checks things in cleanup whereas you might not need the extra fields injected earlier in that method. The other thing I was struggling with is, how I actually integrate the worker in to my service. I have a RequestFilter working from AppModule which is executed for every request. But how do I use the worker class I have just created? I could just call the transform method, but where do I get the ClassTransformation object from. I assume there is some correct way to apply a ComponentClassTransformWorker to a component Yes, just contribute to the class transform worker, like this, and Tapestry will take care of running it on your classes. public static void contributeComponentClassTransformWorker( OrderedConfigurationComponentClassTransformWorker configuration, SecurityChecker securityChecker) { configuration.add(Acegi, new AcegiWorker(securityChecker)); } -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/27/07, Erik Vullings [EMAIL PROTECTED] wrote: Hi, Just wondering - when dealing with page authorizations, does this model expand to component authorizations, i.e. you may visit the page, but not certain components (redirect to another component), or you can see a component, but with less privileges (e.g. view but not edit). In other words, how would you deal with CRUD (create, read, update, delete) role-based authorization on a component level? I'd say it's up to the component. I've just added two new components in tapestry5-acegi, called IfLoggedIn and IfRole, which can be used in components such as: t:security.ifloggedin You are logged in, welcome! t:security.ifrole role=ROLE_ADMIN You are even logged as admin, cool! t:parameter name=else Sorry, you don't have admin credentials. /t:parameter /t:security.ifrole a t:type=actionlink t:id=logoutLogout/a t:parameter name=else Not logged in, please t:pagelink t:page=LoginPagedo/t:pagelink. /t:parameter /t:security.ifloggedin -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/25/07, Nick Westgate (Work) [EMAIL PROTECTED] wrote: Also, just as a reminder, base classes must not go in the pages package. I thinks that's where my RistrictedPage class was going wrong. I think I will play around with trying to create some tapestry5-acegi like annotations and request filters. ACEGI I think is a bit more than I need. However I use the same base login / user management package I created for a few sites, so I think it would pay to get the restricting of pages right for all the new Tapestry 5 versions. Plus its a good exercise in learning some of the more complicated bits of Tapestry 5. Thanks for all, the help. Charlie M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/24/07, Robin Helgelin [EMAIL PROTECTED] wrote: To ask your second question, the code tapestry5-acegi uses to wrap around the class is found here in this service: http://www.localhost.nu/svn/public/tapestry5-acegi/trunk/src/main/java/nu/localhost/tapestry/acegi/services/internal/AcegiWorker.java Thanks for the info. I had been studying the code for a while. I didn't look at that class much because I assumed from its title it was dealing with the acegi library work rather than the tapestry side of things. I should have known better than to assume things from class names :) What I want to do is have a SecuredPage annotation, which can be added to any page class. Then before any page annotated with SecuredPage is run, it calls a method that decides wither or not to redirect the user to another page, bassed on there login info from the Application State. I have made my own worker class, annotation and service. I understand the acegi worker class except for the transform page part. I can't work out how its managing to change the page. Its clearly modifying a method but, I cant really work out how. The other thing I was struggling with is, how I actually integrate the worker in to my service. I have a RequestFilter working from AppModule which is executed for every request. But how do I use the worker class I have just created? I could just call the transform method, but where do I get the ClassTransformation object from. I assume there is some correct way to apply a ComponentClassTransformWorker to a component Any help / suggestions would be really appreciated. Charlie M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[T5] Restricting Page Access
Firstly I just want to say Tapestry 5 is amazing, Tapestry 4 was very good but Tapestry 5 is outstanding. One thing I haven't figured out how to do the Tapestry 5 way is controlling page access. On many sites I write there is often a need to password protect a large number of pages. The way I usually do it in Tapestry 4 was to put an object in the application state once the user logged in. Then every restricted page was a sub class of my RestrictedPage class. The RestrictedPage class was a subclass of Page, which when activated check the existence of the Application Sate Object. If the user wasn't logged in there was no application state object they weren't logged in. I have been trying to do a similar thing in Tapestry 5, my first problem was that I couldn't get all of the annotations and special methods (like onActivate) to work if declared in the base class RestrictedPage. The same code worked fine in the actual page class, however I don't really want a big chunk of identical code in every class of a restricted page, as that would make future changes to the login system difficult. I assume its a feature rather than a bug that these annotations and special methods don't work if defined in the base class. I was looking at various solutions to this and found the Tapestry 5 acegi library, http://www.localhost.nu/java/tapestry5-acegi/ It has a really nice secured annotation to do a similar thing e.g. @Secured(ROLE_ADMIN) public class AdminPage { } I was wondering how this worked. I am assuming its through some sort of T5 service. I was looking at the documentation on the T5 site, although I can't figure how to do something like that. I also had a look at the Tapestry 5 acegi library. But not knowing acegi, its hard to see how this works in the source. I was wondering if someone could tell me the basic principle of what I need to write or implement to be able to hook in the to the page loading procedure from just an annotation. Charlie M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
On 8/24/07, Charles Mason [EMAIL PROTECTED] wrote: @Secured(ROLE_ADMIN) public class AdminPage { } I was wondering how this worked. I am assuming its through some sort of T5 service. I was looking at the documentation on the T5 site, although I can't figure how to do something like that. I also had a look at the Tapestry 5 acegi library. But not knowing acegi, its hard to see how this works in the source. I was wondering if someone could tell me the basic principle of what I need to write or implement to be able to hook in the to the page loading procedure from just an annotation. The tapestry5-acegi library adds a few request filters that run between your browser and the T5 engine. It also adds a few hooks to your classes defined by the @Secured annotation. These hooks are executed before your class by a few Acegi classes which checks right permissions/roles, etc and either gives you access to the page or redirects you to the defined login page. Depending on your needs, Acegi might be the bigger hammer to punch the little nail :-). To ask your second question, the code tapestry5-acegi uses to wrap around the class is found here in this service: http://www.localhost.nu/svn/public/tapestry5-acegi/trunk/src/main/java/nu/localhost/tapestry/acegi/services/internal/AcegiWorker.java -- regards, Robin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
If you have a base class for your protected pages then onActivate event will trigger first on the parent then in the child if return value of the parent onActivate event is null. This work fine in my project, I don´t use any annotation for this just declare: public abstract class SecurePage{ Class onActivate(){ // check security return null if ok } } then public class myPage{ void onActivate(){ // do something } } Regards César. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
A little mistake myPage MUST extends SecurePage of course :) On 8/24/07, César Lesc [EMAIL PROTECTED] wrote: If you have a base class for your protected pages then onActivate event will trigger first on the parent then in the child if return value of the parent onActivate event is null. This work fine in my project, I don´t use any annotation for this just declare: public abstract class SecurePage{ Class onActivate(){ // check security return null if ok } } then public class myPage{ void onActivate(){ // do something } } Regards César. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Restricting Page Access
Also, just as a reminder, base classes must not go in the pages package. Cheers, Nick. César Les wrote: A little mistake myPage MUST extends SecurePage of course :) On 8/24/07, César Lesc [EMAIL PROTECTED] wrote: If you have a base class for your protected pages then onActivate event will trigger first on the parent then in the child if return value of the parent onActivate event is null. This work fine in my project, I don´t use any annotation for this just declare: public abstract class SecurePage{ Class onActivate(){ // check security return null if ok } } then public class myPage{ void onActivate(){ // do something } } Regards César. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-T5--Restricting-Page-Access-tf4325658.html#a12321896 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]