Re: Authentication Tapestry 5
Peter Stavrinides a écrit : Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, [...] Thanks in advance, Peter Hi, First, I'm a real Tapestry newbie, and I believe that Tapestry has a quite steep learning curve (at last for T5 with current documentation). I wish to use JAAS inside my webapp, and I didn't achieve to use a Tapestry login form. So I'm using a basic html page with Tomcat out of box security login config. Magically, I'm able to retrieve my principal in the JBoss EJB3 context. I use those EJBs for authorizations, Tapestry just not knows if users have rights on data, as I delegate only the V of MVC to Tapestry. If a user doesn't have right on something, a security exception is thrown by the model and displayed back to him. A better solution would be having one namespace dedicated to login users, not protected by servlet container. A Tapestry component would be able to login user, and redirect him to a component in another namespace, this one protected by a security-constraint. I'm just more confident in servlet container security filtering than in a home made filter. So, how can I login my user inside my component and be able to retrieve my principal with RequestGlobals.getHTTPServletRequest().getUserPrincipal()? Thanks, Gabriel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
Hi Gabriel
I have a similar setup using a JDBC realm as well as multiple
applications running on the domain so the best solution for me was to
look for the authorization header in the browser and use this info to
authenticate
Chris posted a great wiki article on how to implement a Dispatcher or
RequestFilter to handle the authentication, I don't know if anyone has a
better solution than this but I get to the servlet context by adding
constructor arguments to the wiki example:
public AccessController(
ApplicationStateManager asm,
RequestGlobals requestGlobals){
this.request_ = requestGlobals.getHTTPServletRequest();
this.response_ = requestGlobals.getHTTPServletResponse();
this.asm_ = asm;
}
seems to work,
Peter
Gabriel Landais wrote:
Peter Stavrinides a écrit :
Hi all
My question is more of a best practice related question, I want to
use a filter to extract my authentication code from the rest of the
application logic, [...]
Thanks in advance,
Peter
Hi,
First, I'm a real Tapestry newbie, and I believe that Tapestry has a
quite steep learning curve (at last for T5 with current documentation).
I wish to use JAAS inside my webapp, and I didn't achieve to use a
Tapestry login form. So I'm using a basic html page with Tomcat out of
box security login config. Magically, I'm able to retrieve my principal
in the JBoss EJB3 context. I use those EJBs for authorizations, Tapestry
just not knows if users have rights on data, as I delegate only the V
of MVC to Tapestry. If a user doesn't have right on something, a
security exception is thrown by the model and displayed back to him.
A better solution would be having one namespace dedicated to login
users, not protected by servlet container. A Tapestry component would be
able to login user, and redirect him to a component in another
namespace, this one protected by a security-constraint. I'm just more
confident in servlet container security filtering than in a home made
filter.
So, how can I login my user inside my component and be able to retrieve
my principal with
RequestGlobals.getHTTPServletRequest().getUserPrincipal()?
Thanks,
Gabriel
-
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]
Re: Authentication Tapestry 5
Hi Chris, Thanks for the great wiki article, I have managed to implement what I needed using 'Tapestry5HowToCreateADispatcher2'. My implementation is very similar to the example... it seems to work great! One question though regarding my ASO (which is similar to your permissions ASO), you mention the object referenced by 'perms' is an instance specific to the current request does this mean that I will *not* get the very same instance if I try inject it in a page class using the @ApplicationState annotation? Thanks Peter Chris Lewis wrote: Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
Hi Peter, I'll ask Howard to verify what I say here as its a pretty important issue. Short answer: Yes, you will get the same instance using the state manager as you would from injection via @ApplicationState... for simultaneous requests made by the same user (and therefore the same request/session). That is a very simplified answer. Its important to understand why you can use @ApplicationState in a page but not in a singleton service. If you read both wikis and/or docs on the state manager, you should already have a basic understanding. Under the hood, T5 IoC uses the state manager to retrieve page members marked as state objects with the @ApplicationState annotation. Why? Because an instance of a page class may be accessed simultaneously by many different requests at the same time. In reality the annotation is just an indicator that a page member is specific to the current request, NOT the page. Its up to the IoC container to resolve exactly what request (session) is associated with the requesting user, and ultimately which instance of your ASO class. I'm quite sure this work is done by the state manager. hope that helps sincerely, chris Peter Stavrinides wrote: Hi Chris, Thanks for the great wiki article, I have managed to implement what I needed using 'Tapestry5HowToCreateADispatcher2'. My implementation is very similar to the example... it seems to work great! One question though regarding my ASO (which is similar to your permissions ASO), you mention the object referenced by 'perms' is an instance specific to the current request does this mean that I will *not* get the very same instance if I try inject it in a page class using the @ApplicationState annotation? Thanks Peter Chris Lewis wrote: Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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] - 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]
Re: Authentication Tapestry 5
Actually by indirection it is also my problem ;-), and I'd like to know if you find this not to be true. I have done some digging and chatting (on this list) about this topic, and for all I've found this appears to be how it is designed. As such I shape my ideas and plans around this understanding, so if it's wrong then I'm in trouble ;-). Share some code if you have some that suggests otherwise, and hopefully Howard will chime in if I'm off. sincerely, chris Peter Stavrinides wrote: Hi Chris, Thanks for the clarification, this is what I had initially thought... however some quick and dirty tests made me doubt this, I am not sure why it didn't turn up for me that way, I will have to check my code again ... not your problem anyway. Thanks again, Peter Chris Lewis wrote: Hi Peter, I'll ask Howard to verify what I say here as its a pretty important issue. Short answer: Yes, you will get the same instance using the state manager as you would from injection via @ApplicationState... for simultaneous requests made by the same user (and therefore the same request/session). That is a very simplified answer. Its important to understand why you can use @ApplicationState in a page but not in a singleton service. If you read both wikis and/or docs on the state manager, you should already have a basic understanding. Under the hood, T5 IoC uses the state manager to retrieve page members marked as state objects with the @ApplicationState annotation. Why? Because an instance of a page class may be accessed simultaneously by many different requests at the same time. In reality the annotation is just an indicator that a page member is specific to the current request, NOT the page. Its up to the IoC container to resolve exactly what request (session) is associated with the requesting user, and ultimately which instance of your ASO class. I'm quite sure this work is done by the state manager. hope that helps sincerely, chris Peter Stavrinides wrote: Hi Chris, Thanks for the great wiki article, I have managed to implement what I needed using 'Tapestry5HowToCreateADispatcher2'. My implementation is very similar to the example... it seems to work great! One question though regarding my ASO (which is similar to your permissions ASO), you mention the object referenced by 'perms' is an instance specific to the current request does this mean that I will *not* get the very same instance if I try inject it in a page class using the @ApplicationState annotation? Thanks Peter Chris Lewis wrote: Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
will do! Peter Chris Lewis wrote: Actually by indirection it is also my problem ;-), and I'd like to know if you find this not to be true. I have done some digging and chatting (on this list) about this topic, and for all I've found this appears to be how it is designed. As such I shape my ideas and plans around this understanding, so if it's wrong then I'm in trouble ;-). Share some code if you have some that suggests otherwise, and hopefully Howard will chime in if I'm off. sincerely, chris Peter Stavrinides wrote: Hi Chris, Thanks for the clarification, this is what I had initially thought... however some quick and dirty tests made me doubt this, I am not sure why it didn't turn up for me that way, I will have to check my code again ... not your problem anyway. Thanks again, Peter Chris Lewis wrote: Hi Peter, I'll ask Howard to verify what I say here as its a pretty important issue. Short answer: Yes, you will get the same instance using the state manager as you would from injection via @ApplicationState... for simultaneous requests made by the same user (and therefore the same request/session). That is a very simplified answer. Its important to understand why you can use @ApplicationState in a page but not in a singleton service. If you read both wikis and/or docs on the state manager, you should already have a basic understanding. Under the hood, T5 IoC uses the state manager to retrieve page members marked as state objects with the @ApplicationState annotation. Why? Because an instance of a page class may be accessed simultaneously by many different requests at the same time. In reality the annotation is just an indicator that a page member is specific to the current request, NOT the page. Its up to the IoC container to resolve exactly what request (session) is associated with the requesting user, and ultimately which instance of your ASO class. I'm quite sure this work is done by the state manager. hope that helps sincerely, chris Peter Stavrinides wrote: Hi Chris, Thanks for the great wiki article, I have managed to implement what I needed using 'Tapestry5HowToCreateADispatcher2'. My implementation is very similar to the example... it seems to work great! One question though regarding my ASO (which is similar to your permissions ASO), you mention the object referenced by 'perms' is an instance specific to the current request does this mean that I will *not* get the very same instance if I try inject it in a page class using the @ApplicationState annotation? Thanks Peter Chris Lewis wrote: Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
Hi Chris, You wrote: manager to retrieve page members marked as state objects with the @ApplicationState annotation. Why? Because an instance of a page class may be accessed simultaneously by many different requests at the same time. In reality the annotation is just an indicator that a page I don't think this is actually correct. Definitely in Tap4 and a quick reading of the lifecycle page for Tap5 suggests that an instance of a page is locked to a request for the duration of that request. This also means it is on a single thread (ie the thread handling the request) for the duration of the request. This is why pages are pooled - because you may need more than one instance of a page to handle simultaneous requests. That is my understanding anyway Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
From http://tapestry.apache.org/tapestry5/tapestry-core/guide/lifecycle.html: This is how Tapestry keeps you from worrying about multi-threading issues ... the objects involved in any request are reserved to just that request (and just that thread). So I think you are right. Let me amend my statement by saying that an instance of a page class will be reused. Naturally this would suggest that stale values from other requests (and therefore other clients) would show up on the pages of other users (and indeed they do, without proper care). So @ApplicationState must remind the IoC container that whenever a page is attached to a request, it must populate the state objects according to the attached session. Thanks :-) Richard Kirby wrote: Hi Chris, You wrote: manager to retrieve page members marked as state objects with the @ApplicationState annotation. Why? Because an instance of a page class may be accessed simultaneously by many different requests at the same time. In reality the annotation is just an indicator that a page I don't think this is actually correct. Definitely in Tap4 and a quick reading of the lifecycle page for Tap5 suggests that an instance of a page is locked to a request for the duration of that request. This also means it is on a single thread (ie the thread handling the request) for the duration of the request. This is why pages are pooled - because you may need more than one instance of a page to handle simultaneous requests. That is my understanding anyway Richard - 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]
Authentication Tapestry 5
Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Tapestry 5
Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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]
Re: Authentication Tapestry 5
Hi Chris Yes, this is kind of what I am looking for, I will give it a go... Thanks Peter Chris Lewis wrote: Hello Peter, It sounds like by 'filter' you mean a servlet filter and not a Tapestry filter. Your requirements sound a tad exotic to me, but these wikis should get you on the right track: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 They focus on implementing authentication/restriction code completely outside of the 'page' level of the application. The focus on these is the required infrastructure, so there are some holes left to be filled. At any rate they should be useful for you. Note that the same thing can be achieved using a Tapestry filter: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html Sincerely, Chris Peter Stavrinides wrote: Hi all My question is more of a best practice related question, I want to use a filter to extract my authentication code from the rest of the application logic, so I can avoid adding this logic to pages. In addition, one of my authentication requirements involves some integration with third party applications so I need to check for authentication headers... to accommodate this I use a session state object in my app (i.e. a T5 service), which is available for the duration of a users session. Implementing an ordinary servlet filter would do the trick for the authentication part... but then I wouldn't be able to use it with the IoC service. So: 1. Is there a way to register my filter with Tapestry IoC instead of registering it in web.xml? (would I create a contribution to the framework?) 2. Can I inject this service (i.e. my state object )into the filter? and what does this involve i.e. eager loading etc? I am not sure I am going about this the right way, if someone has done something similar could I get some pointers. Thanks in advance, Peter - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
