You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Daniel Jones <da...@murieston.com> on 2009/02/05 11:24:29 UTC
Protecting ActionLinks when using a Dispatcher.
Hi there,
I have implemented and contributed a Dispatcher in order to secure access to
pages based on the users role. This is similar to the tutorial on the wiki,
although I have used annotations, so I can attach @Secured("ROLE_ADMIN") to
the page class. This works very well and the user is redirected to the
login page if they do not have the required privileges.
So my problem is that ActionLinks on these pages are unprotected. If I was
a malicious user and somehow managed to guess the URL to one of these
actions, even though they are redirected to the login page by my Dispatcher,
the action is still invoked.
How do I protect these links, and is the same true for forms as well? What
do I need to implement in order to catch these requests (RequestFilter?)
Ideally, if my dispatcher deems that the user does not have enough
privilidges (the page is @Secured("ROLE_ADMIN") for instance) then all of
the action links on this page would also require this role to be invoked.
On pages where the the role required is less than admin, for example,
ROLE_USER, these pages could contain actions that are only for
administrators, so it would be nice to attach an annotation to the
onAction() methods where increased security is required.
If someone can shed some light on the best way of implementing this I would
appreciate it very much. I don't want to write boilerplate code at the
start of every onAction() method that needs to be secured, and I don't want
to extend base classes or mess about with onActivate() so ideally I would
like a solution that is similar to the dispatcher or some sort of filter.
Many Thanks,
Daniel
--
View this message in context: http://www.nabble.com/Protecting-ActionLinks-when-using-a-Dispatcher.-tp21848757p21848757.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Feb 6, 2009 at 9:49 AM, Jonathan O'Connor <ni...@eircom.net> wrote:
> Thiago,
> firstly, I assumed you meant "Normal" == "the Tapestry Dispatcher", but my
> point is that the 4 Tapestry built-in Dispatchers (AssetDispatcher,
> ComponentEventDispatcher, PageRenderDispatcher and RootPathDispatcher) are
> no different to my JonathansFunkyDispatcher, and nor should they.
You're absolutely right. I shouldn't give opinions about something I
haven't worked with (Dispatchers). :)
> BTW, after your comment about loading a page just to check the annotations,
> I went looking at the ComponentClassResolver. It has a neat method:
> resolvePageNameToClassName(String logicalPageName). Then I can ask a
> classloader for the class, and bingo! No more page instanciation.
I forgot about that method. I have used it already. Thanks for
refreshing my memory!
Tchau!
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Jonathan O'Connor <ni...@eircom.net>.
Thiago,
firstly, I assumed you meant "Normal" == "the Tapestry Dispatcher", but
my point is that the 4 Tapestry built-in Dispatchers (AssetDispatcher,
ComponentEventDispatcher, PageRenderDispatcher and RootPathDispatcher)
are no different to my JonathansFunkyDispatcher, and nor should they.
Anyway, it seems Howard has a new interface in Tap 5.1.
BTW, after your comment about loading a page just to check the
annotations, I went looking at the ComponentClassResolver. It has a neat
method: resolvePageNameToClassName(String logicalPageName). Then I can
ask a classloader for the class, and bingo! No more page instanciation.
Ciao,
Jonathan
On 06/02/2009 11:22, Thiago H. de Paula Figueiredo wrote:
> On Thu, Feb 5, 2009 at 10:43 PM, Jonathan O'Connor<ni...@eircom.net> wrote:
>
>> Thiago,
>>
>
> Hi!
>
>
>> I guess you want the Class if your doing annotation based protection, and
>> the string if you have some sort of map.
>>
>
> You're right. My needs are different from yours. :)
>
>
>> But, as Daniel mentioned, you can
>> get a ComponentSource, and convert the string to a Class, so no problems
>> there.
>>
>
> This isn't the best way to do it because a component or page would be
> instantiated just for the sake of knowing what page/component class.
>
>
>> The problem is deciding what a normally dispatched request is.
>>
>
> I could have chosen better words. When I said normal, I meant
> "dispatched by the Tapestry dispatcher". ;)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, Feb 5, 2009 at 10:43 PM, Jonathan O'Connor <ni...@eircom.net> wrote:
> Thiago,
Hi!
> I guess you want the Class if your doing annotation based protection, and
> the string if you have some sort of map.
You're right. My needs are different from yours. :)
> But, as Daniel mentioned, you can
> get a ComponentSource, and convert the string to a Class, so no problems
> there.
This isn't the best way to do it because a component or page would be
instantiated just for the sake of knowing what page/component class.
> The problem is deciding what a normally dispatched request is.
I could have chosen better words. When I said normal, I meant
"dispatched by the Tapestry dispatcher". ;)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Jonathan O'Connor <ni...@eircom.net>.
Thiago,
I guess you want the Class if your doing annotation based protection,
and the string if you have some sort of map. But, as Daniel mentioned,
you can get a ComponentSource, and convert the string to a Class, so no
problems there.
The problem is deciding what a normally dispatched request is.
Tapestry's whole philosophy is that my dispatcher/Service/Component is
as normal as any other dispatcher/Service/Component. Just today I saw
some messages about more RESTful URLs, that get converted to a page with
parameters. Any dispatcher that converts the request to a Page/Component
class will need to be involved in the complete solution.
Hmm, interesting design problem. It's after midnight here, so maybe I'll
think some more tomorrow.
Ciao,
Jonathan
On 05/02/2009 20:51, Thiago H. de Paula Figueiredo wrote:
> Em Thu, 05 Feb 2009 15:20:02 -0300, Jonathan O'Connor
> <ni...@eircom.net> escreveu:
>
>> Thiago,
>
> Hi!
>
>> I thought about the service idea, but what would it look like?
>> Class extractPageClass(String requestPath) would be what I'd want.
>
> That's what I want too. I would add a String extractPageName(String
> requestPath), returning the Tapestry page name (something like
> admin/user/edit).
>
>> However, for each Dispatcher, you'd want a PageClassExtracter as
>> well, and I'm sure there'd be lots of duplication.
>
> I haven't thought of the dispatcher issue yet, but maybe we could
> suppose that our new service would deal only with normally-dispatched
> requests.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Jonathan O'Connor <ni...@eircom.net>.
Howard,
this saves me any more cogitation for now!
Ciao,
Jonathan
On 05/02/2009 20:11, Howard Lewis Ship wrote:
> The ComponentRequestHandler pipeline (new in 5.1) is for this purpose.
> You can contribute a ComponentRequestFilter; your filter is passed
> all the details of the request (page names, nested ids, page
> activation context, event context) and can decide how to proceed.
>
> CRH pipeline is a facade around two different pipelines:
> ComponentEventRequestHandler and PageRenderRequestHandler. In some
> cases, you may want to contribute a filter to once of those pipelines
> instead.
>
>
> On Thu, Feb 5, 2009 at 12:51 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>
>> Em Thu, 05 Feb 2009 15:20:02 -0300, Jonathan O'Connor<ni...@eircom.net>
>> escreveu:
>>
>>
>>> Thiago,
>>>
>> Hi!
>>
>>
>>> I thought about the service idea, but what would it look like?
>>> Class extractPageClass(String requestPath) would be what I'd want.
>>>
>> That's what I want too. I would add a String extractPageName(String
>> requestPath), returning the Tapestry page name (something like
>> admin/user/edit).
>>
>>
>>> However, for each Dispatcher, you'd want a PageClassExtracter as well, and
>>> I'm sure there'd be lots of duplication.
>>>
>> I haven't thought of the dispatcher issue yet, but maybe we could suppose
>> that our new service would deal only with normally-dispatched requests.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>> ---------------------------------------------------------------------
>> 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: Protecting ActionLinks when using a Dispatcher.
Posted by Howard Lewis Ship <hl...@gmail.com>.
The ComponentRequestHandler pipeline (new in 5.1) is for this purpose.
You can contribute a ComponentRequestFilter; your filter is passed
all the details of the request (page names, nested ids, page
activation context, event context) and can decide how to proceed.
CRH pipeline is a facade around two different pipelines:
ComponentEventRequestHandler and PageRenderRequestHandler. In some
cases, you may want to contribute a filter to once of those pipelines
instead.
On Thu, Feb 5, 2009 at 12:51 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Thu, 05 Feb 2009 15:20:02 -0300, Jonathan O'Connor <ni...@eircom.net>
> escreveu:
>
>> Thiago,
>
> Hi!
>
>> I thought about the service idea, but what would it look like?
>> Class extractPageClass(String requestPath) would be what I'd want.
>
> That's what I want too. I would add a String extractPageName(String
> requestPath), returning the Tapestry page name (something like
> admin/user/edit).
>
>> However, for each Dispatcher, you'd want a PageClassExtracter as well, and
>> I'm sure there'd be lots of duplication.
>
> I haven't thought of the dispatcher issue yet, but maybe we could suppose
> that our new service would deal only with normally-dispatched requests.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 05 Feb 2009 15:20:02 -0300, Jonathan O'Connor
<ni...@eircom.net> escreveu:
> Thiago,
Hi!
> I thought about the service idea, but what would it look like?
> Class extractPageClass(String requestPath) would be what I'd want.
That's what I want too. I would add a String extractPageName(String
requestPath), returning the Tapestry page name (something like
admin/user/edit).
> However, for each Dispatcher, you'd want a PageClassExtracter as well,
> and I'm sure there'd be lots of duplication.
I haven't thought of the dispatcher issue yet, but maybe we could suppose
that our new service would deal only with normally-dispatched requests.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Daniel Jones <da...@murieston.com>.
Hi Jonathan,
Thanks for your input so far.
I have managed to solve the problem by borrowing some code from
ComponentEventDispatcher and PageRenderDispatcher. The beast of a regexp in
ComponentEventDispatcher provides a means to get the 'activePageName' but
this includes the context as well. There is code in the
PageRenderDispatcher to strip out the context which leaves you with the page
name.
With the page name you can get the page class by injecting ComponentSource
and passing the page name to the getPage(pageName) method.
Also if you follow the wiki tutorial it tells you to place your dispatcher
before the PageRender stage. To intercept event links, you must place it
before the ComponentEvent stage otherwise event links will be eaten by the
ComponentEventDispatcher before they reach your code.
Daniel
Jonathan O'Connor-3 wrote:
>
> Thiago,
> I thought about the service idea, but what would it look like?
> Class extractPageClass(String requestPath) would be what I'd want.
>
> However, for each Dispatcher, you'd want a PageClassExtracter as well,
> and I'm sure there'd be lots of duplication. To stay DRY, I guess we
> have to add the extractPageClass method to the Dispatcher interface,
> which is not very nice, especially as the AssetDispatcher does not use
> pages. Maybe we could extend Dispatcher to UsesPagesDispatcher that has
> our method. Now, we can iterate through the Dispatcher pipeline, and
> call extractPageClass only on the UsesPagesDispatchers.
>
> Does that all make sense? Or is there a better way?
> Ciao,
> Jonathan
>
> On 05/02/2009 18:59, Thiago H. de Paula Figueiredo wrote:
>> Em Thu, 05 Feb 2009 07:40:24 -0300, Jonathan O'Connor
>> <ni...@eircom.net> escreveu:
>>
>>> Daniel,
>>> I was looking at this problem the other day, and you should look at
>>> the ComponentEventDispatcher. I think you need to first check if you
>>> get a matching page, and then check if you have an event. You can
>>> then extract the Pagename from the request path using that monster
>>> Reg exp. Sadly, this all relies on internal code :-(
>>
>> I have the same need of extracting the page name from a Request.
>> Should we file a JIRA to have a public service that does that?
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Protecting-ActionLinks-when-using-a-Dispatcher.-tp21848757p21858880.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Jonathan O'Connor <ni...@eircom.net>.
Thiago,
I thought about the service idea, but what would it look like?
Class extractPageClass(String requestPath) would be what I'd want.
However, for each Dispatcher, you'd want a PageClassExtracter as well,
and I'm sure there'd be lots of duplication. To stay DRY, I guess we
have to add the extractPageClass method to the Dispatcher interface,
which is not very nice, especially as the AssetDispatcher does not use
pages. Maybe we could extend Dispatcher to UsesPagesDispatcher that has
our method. Now, we can iterate through the Dispatcher pipeline, and
call extractPageClass only on the UsesPagesDispatchers.
Does that all make sense? Or is there a better way?
Ciao,
Jonathan
On 05/02/2009 18:59, Thiago H. de Paula Figueiredo wrote:
> Em Thu, 05 Feb 2009 07:40:24 -0300, Jonathan O'Connor
> <ni...@eircom.net> escreveu:
>
>> Daniel,
>> I was looking at this problem the other day, and you should look at
>> the ComponentEventDispatcher. I think you need to first check if you
>> get a matching page, and then check if you have an event. You can
>> then extract the Pagename from the request path using that monster
>> Reg exp. Sadly, this all relies on internal code :-(
>
> I have the same need of extracting the page name from a Request.
> Should we file a JIRA to have a public service that does that?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 05 Feb 2009 07:40:24 -0300, Jonathan O'Connor
<ni...@eircom.net> escreveu:
> Daniel,
> I was looking at this problem the other day, and you should look at the
> ComponentEventDispatcher. I think you need to first check if you get a
> matching page, and then check if you have an event. You can then extract
> the Pagename from the request path using that monster Reg exp. Sadly,
> this all relies on internal code :-(
I have the same need of extracting the page name from a Request. Should we
file a JIRA to have a public service that does that?
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Protecting ActionLinks when using a Dispatcher.
Posted by Jonathan O'Connor <ni...@eircom.net>.
Daniel,
I was looking at this problem the other day, and you should look at the
ComponentEventDispatcher. I think you need to first check if you get a
matching page, and then check if you have an event. You can then extract
the Pagename from the request path using that monster Reg exp. Sadly,
this all relies on internal code :-(
Maybe there's a service for extracting the pagename from any request,
but I guess that's not possible, because of the way people contribute
Dispatchers.
Hope this helps,
Jonathan
On 05/02/2009 10:24, Daniel Jones wrote:
> Hi there,
>
> I have implemented and contributed a Dispatcher in order to secure access to
> pages based on the users role. This is similar to the tutorial on the wiki,
> although I have used annotations, so I can attach @Secured("ROLE_ADMIN") to
> the page class. This works very well and the user is redirected to the
> login page if they do not have the required privileges.
>
> So my problem is that ActionLinks on these pages are unprotected. If I was
> a malicious user and somehow managed to guess the URL to one of these
> actions, even though they are redirected to the login page by my Dispatcher,
> the action is still invoked.
>
> How do I protect these links, and is the same true for forms as well? What
> do I need to implement in order to catch these requests (RequestFilter?)
> Ideally, if my dispatcher deems that the user does not have enough
> privilidges (the page is @Secured("ROLE_ADMIN") for instance) then all of
> the action links on this page would also require this role to be invoked.
>
> On pages where the the role required is less than admin, for example,
> ROLE_USER, these pages could contain actions that are only for
> administrators, so it would be nice to attach an annotation to the
> onAction() methods where increased security is required.
>
> If someone can shed some light on the best way of implementing this I would
> appreciate it very much. I don't want to write boilerplate code at the
> start of every onAction() method that needs to be secured, and I don't want
> to extend base classes or mess about with onActivate() so ideally I would
> like a solution that is similar to the dispatcher or some sort of filter.
>
> Many Thanks,
> Daniel
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org