You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Lewis <ch...@bellsouth.net> on 2007/11/19 14:30:59 UTC
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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Peter Stavrinides <p....@albourne.com>.
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: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Chris Lewis <ch...@bellsouth.net>.
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: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Peter Stavrinides <p....@albourne.com>.
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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Chris Lewis <ch...@bellsouth.net>.
>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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Richard Kirby <rb...@capdm.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Chris Lewis <ch...@bellsouth.net>.
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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Peter Stavrinides <p....@albourne.com>.
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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Authentication Tapestry 5
Posted by Peter Stavrinides <p....@albourne.com>.
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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org