You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andrey Larionov <an...@gmail.com> on 2009/08/20 15:31:21 UTC
Way to implement access control
I try to implement federated authorization. I decide to create
RequestFilter which gets cookie value and validate it using federated
server. If validation successful it recives an username and populates
SSO object describes user identity and places in ApplicationState. If
validation failed as SSO stores GuestIdentity.
Is it good solution from tapestry architecture point of view? If it
is, there is a problem: how to obtain user IP address? In
RequsetFilter.service method passes Request object which dosn't
provide user ip information. How to obtain it? Should i use
HttpServletRequestFilter instead? If so, could i operate
ApplicationState in them?
Thanks
Andrey Larionov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Aug 2009 11:19:05 -0300, Andrey Larionov <an...@gmail.com>
escreveu:
> My problem is what in Dispatcher or RequestFilter passed an Request
> instance which not provide getRemoteAddr.
You can inject HttpServletRequest on your Dispatcher or RequestFilter. In
this case, I would use a Dispatcher.
--
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: Google Web Toolkit Version 1.7.0
Posted by "Robert, Brice" <Br...@alliancebernstein.com>.
Andreas, Thanks. That's all I needed to know.
-----Original Message-----
From: andreoua@gmail.com [mailto:andreoua@gmail.com] On Behalf Of Andreas Andreou
Sent: Monday, August 24, 2009 6:39 PM
To: Tapestry users
Subject: Re: Google Web Toolkit Version 1.7.0
AFAIK, the credits to Tapestry are due to some code they borrowed relating to
loading localized property files.
On Tue, Aug 25, 2009 at 12:33 AM, Robert,
Brice<Br...@alliancebernstein.com> wrote:
> Hi,
>
> Using Eclipse, I downloaded the latest Google App Engine SDK 1.2.2 along
> with the GWT 1.7.0.
> By creating a GWT template project and running it, there's a server
> poping up in a new window.
> The Info button gives the below Credits.
>
> Tapestry is clearly stated, I thought I would be able to use all
> Tapestry components but by looking at the Jar files provided by the
> Eclipse PlugIn none of Tapestry's artifacts are provided.
>
> Is anyone know about GWT provided with the Google App Engine plugin?
> What component of Tapestry is provided?
>
> I would definitely use Tapestry if provided with Google App Engine.
>
> Thanks,
> Brice
>
> -----------------------------------------------------------
> Google Web Toolkit
> Version 1.7.0
> (Subversion 1.7@5705)
>
> Copyright (c) 2009 Google Inc. All rights reserved. All other product,
> service names, brands, or trademarks, are the property of their
> respective owners.
>
> This product includes software developed by
>
> * The Apache Software Foundation
> * Tomcat (with modifications)
> * Tapestry
>
> * The Eclipse Foundation
> * Java Development Tools
> * Standard Widget Toolkit (with modifications)
> The JFreeChart Project
> The Mort Bay Consulting
> Jetty 6.1.11
> The Mozilla Foundation
> Mozilla 1.7.12
> Rhino (with modifications)
> The ObjectWeb
> ASM (with modifications)
> The OpenQA Project
> Selenium-RC
> For source availability and license information see COPYING.html.
> -----------------------------------------------------------------------------------
> The information contained in the linked e-mail transmission and any
> attachments may be privileged and confidential and is intended only for
> the use of the person(s) named in the linked e-mail transmission. If you
> are not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you should not
> review, disseminate, distribute or duplicate this e-mail transmission or
> any attachments. If you are not the intended recipient, please contact
> the sender immediately by reply e-mail and destroy all copies of the
> original message. We do not accept account orders and/or instructions
> related to AllianceBernstein products or services by e-mail, and
> therefore will not be responsible for carrying out such orders and/or
> instructions. The linked e-mail transmission and any attachments are
> provided for informational purposes only and should not be construed in
> any manner as any solicitation or offer to buy or sell any investment
> opportunities or any related financial instruments and should not be
> construed in any manner as a public offer of any investment
> opportunities or any related financial instruments. If you, as the
> intended recipient of the linked e-mail transmission, the purpose of
> which is to inform and update our clients, prospects and consultants of
> developments relating to our services and products, would not like to
> receive further e-mail correspondence from the sender, please "reply"
> to the sender indicating your wishes. Although we attempt to sweep
> e-mail and attachments for viruses, we will not be liable for any
> damages arising from the alteration of the contents of this linked e-mail
> transmission and any attachments by a third party or as a result of any
> virus being passed on. Please note: Trading instructions sent
> electronically to Bernstein shall not be deemed accepted until a
> representative of Bernstein acknowledges receipt electronically or by
> telephone. Comments in the linked e-mail transmission and any
> attachments are part of a larger body of investment analysis. For our
> research reports, which contain information that may be used to
> support investment decisions, and disclosures, see our website at
> www.bernsteinresearch.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
-----------------------------------------------------------------------------------
The information contained in the linked e-mail transmission and any
attachments may be privileged and confidential and is intended only for
the use of the person(s) named in the linked e-mail transmission. If you
are not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you should not
review, disseminate, distribute or duplicate this e-mail transmission or
any attachments. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. We do not accept account orders and/or instructions
related to AllianceBernstein products or services by e-mail, and
therefore will not be responsible for carrying out such orders and/or
instructions. The linked e-mail transmission and any attachments are
provided for informational purposes only and should not be construed in
any manner as any solicitation or offer to buy or sell any investment
opportunities or any related financial instruments and should not be
construed in any manner as a public offer of any investment
opportunities or any related financial instruments. If you, as the
intended recipient of the linked e-mail transmission, the purpose of
which is to inform and update our clients, prospects and consultants of
developments relating to our services and products, would not like to
receive further e-mail correspondence from the sender, please "reply"
to the sender indicating your wishes. Although we attempt to sweep
e-mail and attachments for viruses, we will not be liable for any
damages arising from the alteration of the contents of this linked e-mail
transmission and any attachments by a third party or as a result of any
virus being passed on. Please note: Trading instructions sent
electronically to Bernstein shall not be deemed accepted until a
representative of Bernstein acknowledges receipt electronically or by
telephone. Comments in the linked e-mail transmission and any
attachments are part of a larger body of investment analysis. For our
research reports, which contain information that may be used to
support investment decisions, and disclosures, see our website at
www.bernsteinresearch.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Google Web Toolkit Version 1.7.0
Posted by Andreas Andreou <an...@di.uoa.gr>.
AFAIK, the credits to Tapestry are due to some code they borrowed relating to
loading localized property files.
On Tue, Aug 25, 2009 at 12:33 AM, Robert,
Brice<Br...@alliancebernstein.com> wrote:
> Hi,
>
> Using Eclipse, I downloaded the latest Google App Engine SDK 1.2.2 along
> with the GWT 1.7.0.
> By creating a GWT template project and running it, there's a server
> poping up in a new window.
> The Info button gives the below Credits.
>
> Tapestry is clearly stated, I thought I would be able to use all
> Tapestry components but by looking at the Jar files provided by the
> Eclipse PlugIn none of Tapestry's artifacts are provided.
>
> Is anyone know about GWT provided with the Google App Engine plugin?
> What component of Tapestry is provided?
>
> I would definitely use Tapestry if provided with Google App Engine.
>
> Thanks,
> Brice
>
> -----------------------------------------------------------
> Google Web Toolkit
> Version 1.7.0
> (Subversion 1.7@5705)
>
> Copyright (c) 2009 Google Inc. All rights reserved. All other product,
> service names, brands, or trademarks, are the property of their
> respective owners.
>
> This product includes software developed by
>
> * The Apache Software Foundation
> * Tomcat (with modifications)
> * Tapestry
>
> * The Eclipse Foundation
> * Java Development Tools
> * Standard Widget Toolkit (with modifications)
> The JFreeChart Project
> The Mort Bay Consulting
> Jetty 6.1.11
> The Mozilla Foundation
> Mozilla 1.7.12
> Rhino (with modifications)
> The ObjectWeb
> ASM (with modifications)
> The OpenQA Project
> Selenium-RC
> For source availability and license information see COPYING.html.
> -----------------------------------------------------------------------------------
> The information contained in the linked e-mail transmission and any
> attachments may be privileged and confidential and is intended only for
> the use of the person(s) named in the linked e-mail transmission. If you
> are not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you should not
> review, disseminate, distribute or duplicate this e-mail transmission or
> any attachments. If you are not the intended recipient, please contact
> the sender immediately by reply e-mail and destroy all copies of the
> original message. We do not accept account orders and/or instructions
> related to AllianceBernstein products or services by e-mail, and
> therefore will not be responsible for carrying out such orders and/or
> instructions. The linked e-mail transmission and any attachments are
> provided for informational purposes only and should not be construed in
> any manner as any solicitation or offer to buy or sell any investment
> opportunities or any related financial instruments and should not be
> construed in any manner as a public offer of any investment
> opportunities or any related financial instruments. If you, as the
> intended recipient of the linked e-mail transmission, the purpose of
> which is to inform and update our clients, prospects and consultants of
> developments relating to our services and products, would not like to
> receive further e-mail correspondence from the sender, please "reply"
> to the sender indicating your wishes. Although we attempt to sweep
> e-mail and attachments for viruses, we will not be liable for any
> damages arising from the alteration of the contents of this linked e-mail
> transmission and any attachments by a third party or as a result of any
> virus being passed on. Please note: Trading instructions sent
> electronically to Bernstein shall not be deemed accepted until a
> representative of Bernstein acknowledges receipt electronically or by
> telephone. Comments in the linked e-mail transmission and any
> attachments are part of a larger body of investment analysis. For our
> research reports, which contain information that may be used to
> support investment decisions, and disclosures, see our website at
> www.bernsteinresearch.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Google Web Toolkit Version 1.7.0
Posted by "Robert, Brice" <Br...@alliancebernstein.com>.
Hi,
Using Eclipse, I downloaded the latest Google App Engine SDK 1.2.2 along
with the GWT 1.7.0.
By creating a GWT template project and running it, there's a server
poping up in a new window.
The Info button gives the below Credits.
Tapestry is clearly stated, I thought I would be able to use all
Tapestry components but by looking at the Jar files provided by the
Eclipse PlugIn none of Tapestry's artifacts are provided.
Is anyone know about GWT provided with the Google App Engine plugin?
What component of Tapestry is provided?
I would definitely use Tapestry if provided with Google App Engine.
Thanks,
Brice
-----------------------------------------------------------
Google Web Toolkit
Version 1.7.0
(Subversion 1.7@5705)
Copyright (c) 2009 Google Inc. All rights reserved. All other product,
service names, brands, or trademarks, are the property of their
respective owners.
This product includes software developed by
* The Apache Software Foundation
* Tomcat (with modifications)
* Tapestry
* The Eclipse Foundation
* Java Development Tools
* Standard Widget Toolkit (with modifications)
The JFreeChart Project
The Mort Bay Consulting
Jetty 6.1.11
The Mozilla Foundation
Mozilla 1.7.12
Rhino (with modifications)
The ObjectWeb
ASM (with modifications)
The OpenQA Project
Selenium-RC
For source availability and license information see COPYING.html.
-----------------------------------------------------------------------------------
The information contained in the linked e-mail transmission and any
attachments may be privileged and confidential and is intended only for
the use of the person(s) named in the linked e-mail transmission. If you
are not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you should not
review, disseminate, distribute or duplicate this e-mail transmission or
any attachments. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. We do not accept account orders and/or instructions
related to AllianceBernstein products or services by e-mail, and
therefore will not be responsible for carrying out such orders and/or
instructions. The linked e-mail transmission and any attachments are
provided for informational purposes only and should not be construed in
any manner as any solicitation or offer to buy or sell any investment
opportunities or any related financial instruments and should not be
construed in any manner as a public offer of any investment
opportunities or any related financial instruments. If you, as the
intended recipient of the linked e-mail transmission, the purpose of
which is to inform and update our clients, prospects and consultants of
developments relating to our services and products, would not like to
receive further e-mail correspondence from the sender, please "reply"
to the sender indicating your wishes. Although we attempt to sweep
e-mail and attachments for viruses, we will not be liable for any
damages arising from the alteration of the contents of this linked e-mail
transmission and any attachments by a third party or as a result of any
virus being passed on. Please note: Trading instructions sent
electronically to Bernstein shall not be deemed accepted until a
representative of Bernstein acknowledges receipt electronically or by
telephone. Comments in the linked e-mail transmission and any
attachments are part of a larger body of investment analysis. For our
research reports, which contain information that may be used to
support investment decisions, and disclosures, see our website at
www.bernsteinresearch.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
There is an advantage of the Filter over the Dispatcher.
The filter is a nested chain, delegating to the next chain from within
the code. It's like a normal servlet filter.
My security filter stores the user of the session into a thread local
and after the request, cleans up the thread local again. This is
necessary as the the Thread is reused in an application server. Here is
the code of the service method
Best Regards
Sebastian Hennebrueder
public boolean service(Request request, Response response,
RequestHandler handler) throws IOException {
String pageName = extractPage(request);
if (pageName != null && !checkAccess(pageName, request, response)) {
return true;
}
boolean result;
BibaSessionState state = sessionStateManager.get(BibaSessionState.class);
try {
userStorage.storeUser(state);
result = handler.service(request, response);
} finally {
userStorage.cleanUp(state);
}
return result;
}
Ulrich Stärk schrieb:
> In Tapestry, Request abstracts away from either a HttpServletRequest or
> a PortletRequest (not implemented yet). So to make your application work
> in both a Portlet and a Servlet context, you have to use the Request.
> But since you have to get hold of the HttpServletRequest you are
> nevertheless stuck to a Servlet context and it doesn't matter whether
> you write a HttpServletRequestFilter, a RequestFilter (and inject the
> HttpServletRequest) or a Dispatcher (and inject the HttpServletRequest).
> Just choose one.
>
> Uli
>
> Andrey Larionov schrieb:
>> It's not a hack, but RequestFilters services Request not an
>> HttpServletRequest.
>>
>> On Thu, Aug 20, 2009 at 19:15, Thiago H. de Paula
>> Figueiredo<th...@gmail.com> wrote:
>>> Em Thu, 20 Aug 2009 11:54:02 -0300, Andrey Larionov
>>> <an...@gmail.com>
>>> escreveu:
>>>
>>>> Thanks. I decide to try HttpServletRequestFilter, couse injecting
>>>> HttpServletRequest in Dispatcher or RequestFilter looks like a hack.
>>> I don't consider it a hack (injecting services into services is
>>> absolutely
>>> normal in Tapestry and Tapestry-IoC), but an HttpServletRequestFilter
>>> is a
>>> valid choice too.
>>>
>>> --
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by Ulrich Stärk <ul...@spielviel.de>.
In Tapestry, Request abstracts away from either a HttpServletRequest or
a PortletRequest (not implemented yet). So to make your application work
in both a Portlet and a Servlet context, you have to use the Request.
But since you have to get hold of the HttpServletRequest you are
nevertheless stuck to a Servlet context and it doesn't matter whether
you write a HttpServletRequestFilter, a RequestFilter (and inject the
HttpServletRequest) or a Dispatcher (and inject the HttpServletRequest).
Just choose one.
Uli
Andrey Larionov schrieb:
> It's not a hack, but RequestFilters services Request not an HttpServletRequest.
>
> On Thu, Aug 20, 2009 at 19:15, Thiago H. de Paula
> Figueiredo<th...@gmail.com> wrote:
>> Em Thu, 20 Aug 2009 11:54:02 -0300, Andrey Larionov <an...@gmail.com>
>> escreveu:
>>
>>> Thanks. I decide to try HttpServletRequestFilter, couse injecting
>>> HttpServletRequest in Dispatcher or RequestFilter looks like a hack.
>> I don't consider it a hack (injecting services into services is absolutely
>> normal in Tapestry and Tapestry-IoC), but an HttpServletRequestFilter is a
>> valid choice too.
>>
>> --
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by Andrey Larionov <an...@gmail.com>.
It's not a hack, but RequestFilters services Request not an HttpServletRequest.
On Thu, Aug 20, 2009 at 19:15, Thiago H. de Paula
Figueiredo<th...@gmail.com> wrote:
> Em Thu, 20 Aug 2009 11:54:02 -0300, Andrey Larionov <an...@gmail.com>
> escreveu:
>
>> Thanks. I decide to try HttpServletRequestFilter, couse injecting
>> HttpServletRequest in Dispatcher or RequestFilter looks like a hack.
>
> I don't consider it a hack (injecting services into services is absolutely
> normal in Tapestry and Tapestry-IoC), but an HttpServletRequestFilter is a
> valid choice too.
>
> --
> 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: Way to implement access control
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Aug 2009 11:54:02 -0300, Andrey Larionov <an...@gmail.com>
escreveu:
> Thanks. I decide to try HttpServletRequestFilter, couse injecting
> HttpServletRequest in Dispatcher or RequestFilter looks like a hack.
I don't consider it a hack (injecting services into services is absolutely
normal in Tapestry and Tapestry-IoC), but an HttpServletRequestFilter is a
valid choice too.
--
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: Way to implement access control
Posted by Andrey Larionov <an...@gmail.com>.
Thanks. I decide to try HttpServletRequestFilter, couse injecting
HttpServletRequest in Dispatcher or RequestFilter looks like a hack.
If i fail i'll try other ways.
On Thu, Aug 20, 2009 at 18:47, Ulrich Stärk<ul...@spielviel.de> wrote:
> On 20.08.2009 16:37 schrieb Thiago H. de Paula Figueiredo:
>>
>> Em Thu, 20 Aug 2009 11:33:48 -0300, Andrey Larionov <an...@gmail.com>
>> escreveu:
>>
>>> So in my case i should contribute HttpServletRequestFilter? Am i right?
>>
>> If using a RequestFilter, it should be contributed to RequestHandler. If
>> using a Dispatcher, it should be contributed to MasterDispatcher. A good
>> place to look for answers like these is TapestryModule source file.
>>
>> I would use a Dispatcher, as its invoked earlier than a RequestHandler.
>>
>
> Dispatchers are invoked *after* RequestFilters contributed to the
> RequestHandler pipeline.
>
> Uli
>
> ---------------------------------------------------------------------
> 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: Way to implement access control
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Aug 2009 11:47:46 -0300, Ulrich Stärk <ul...@spielviel.de>
escreveu:
> Dispatchers are invoked *after* RequestFilters contributed to the
> RequestHandler pipeline.
Oops. I stand corrected. :)
--
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: Way to implement access control
Posted by Ulrich Stärk <ul...@spielviel.de>.
On 20.08.2009 16:37 schrieb Thiago H. de Paula Figueiredo:
> Em Thu, 20 Aug 2009 11:33:48 -0300, Andrey Larionov
> <an...@gmail.com> escreveu:
>
>> So in my case i should contribute HttpServletRequestFilter? Am i right?
>
> If using a RequestFilter, it should be contributed to RequestHandler. If
> using a Dispatcher, it should be contributed to MasterDispatcher. A good
> place to look for answers like these is TapestryModule source file.
>
> I would use a Dispatcher, as its invoked earlier than a RequestHandler.
>
Dispatchers are invoked *after* RequestFilters contributed to the RequestHandler pipeline.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Aug 2009 11:33:48 -0300, Andrey Larionov <an...@gmail.com>
escreveu:
> So in my case i should contribute HttpServletRequestFilter? Am i right?
If using a RequestFilter, it should be contributed to RequestHandler. If
using a Dispatcher, it should be contributed to MasterDispatcher. A good
place to look for answers like these is TapestryModule source file.
I would use a Dispatcher, as its invoked earlier than a RequestHandler.
--
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: Way to implement access control
Posted by Andrey Larionov <an...@gmail.com>.
So in my case i should contribute HttpServletRequestFilter? Am i right?
On Thu, Aug 20, 2009 at 18:26, Ulrich Stärk<ul...@spielviel.de> wrote:
> It's all about what gets called when. See here [1] for an overv
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by Ulrich Stärk <ul...@spielviel.de>.
It's all about what gets called when. See here [1] for an overview.
Uli
[1] http://uli.spielviel.de/~uli/tapestry_request_processing.png
On 20.08.2009 16:19 schrieb Andrey Larionov:
> My problem is what in Dispatcher or RequestFilter passed an Request
> instance which not provide getRemoteAddr.
> And what is difference beetween Dispatcher and RequestFilter?
> Thanks
>
> On Thu, Aug 20, 2009 at 18:06, Thiago H. de Paula
> Figueiredo<th...@gmail.com> wrote:
>> Em Thu, 20 Aug 2009 10:55:20 -0300, Andrey Larionov <an...@gmail.com>
>> escreveu:
>>
>>> Acegi/Spring is too complicated for my needs :(
>>> The IP is need to validate cookie on federated ID server.
>>> If user change those IP then validation fail and he represented as guest.
>> The wiki shows how to implement it using a Dispatcher. That's the solution I
>> have being using since I dropped Tapestry-Spring-Security (onActivate
>> methods were called before the security checks were made).
>>
>> --
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Way to implement access control
Posted by Andrey Larionov <an...@gmail.com>.
My problem is what in Dispatcher or RequestFilter passed an Request
instance which not provide getRemoteAddr.
And what is difference beetween Dispatcher and RequestFilter?
Thanks
On Thu, Aug 20, 2009 at 18:06, Thiago H. de Paula
Figueiredo<th...@gmail.com> wrote:
> Em Thu, 20 Aug 2009 10:55:20 -0300, Andrey Larionov <an...@gmail.com>
> escreveu:
>
>> Acegi/Spring is too complicated for my needs :(
>> The IP is need to validate cookie on federated ID server.
>> If user change those IP then validation fail and he represented as guest.
>
> The wiki shows how to implement it using a Dispatcher. That's the solution I
> have being using since I dropped Tapestry-Spring-Security (onActivate
> methods were called before the security checks were made).
>
> --
> 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: Way to implement access control
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Aug 2009 10:55:20 -0300, Andrey Larionov <an...@gmail.com>
escreveu:
> Acegi/Spring is too complicated for my needs :(
> The IP is need to validate cookie on federated ID server.
> If user change those IP then validation fail and he represented as guest.
The wiki shows how to implement it using a Dispatcher. That's the solution
I have being using since I dropped Tapestry-Spring-Security (onActivate
methods were called before the security checks were made).
--
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: Way to implement access control
Posted by Andrey Larionov <an...@gmail.com>.
Acegi/Spring is too complicated for my needs :(
The IP is need to validate cookie on federated ID server.
If user change those IP then validation fail and he represented as guest.
On Thu, Aug 20, 2009 at 17:48, Sebastian Hennebrueder<us...@laliluna.de> wrote:
> Andrey Larionov schrieb:
>>
>> I try to implement federated authorization. I decide to create
>> RequestFilter which gets cookie value and validate it using federated
>> server. If validation successful it recives an username and populates
>> SSO object describes user identity and places in ApplicationState. If
>> validation failed as SSO stores GuestIdentity.
>>
>> Is it good solution from tapestry architecture point of view? If it
>> is, there is a problem: how to obtain user IP address? In
>> RequsetFilter.service method passes Request object which dosn't
>> provide user ip information. How to obtain it? Should i use
>> HttpServletRequestFilter instead? If so, could i operate
>> ApplicationState in them?
>>
>> Thanks
>> Andrey Larionov
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
> Hello,
> I can't answer the question on best practise but the wiki has examples to
> create authorization with Acegi/Spring Security. You might use this as
> inspiration.
>
> You talk about IP. There is no guaranty that the same user has the same IP
> in repeated requests. If the user sits behind a proxy cluster, the IP might
> change.
>
> For enterprise security, you might have a look at OWASP ESAPI security as
> well.
>
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
>
>
>
> ---------------------------------------------------------------------
> 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: Way to implement access control
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Andrey Larionov schrieb:
> I try to implement federated authorization. I decide to create
> RequestFilter which gets cookie value and validate it using federated
> server. If validation successful it recives an username and populates
> SSO object describes user identity and places in ApplicationState. If
> validation failed as SSO stores GuestIdentity.
>
> Is it good solution from tapestry architecture point of view? If it
> is, there is a problem: how to obtain user IP address? In
> RequsetFilter.service method passes Request object which dosn't
> provide user ip information. How to obtain it? Should i use
> HttpServletRequestFilter instead? If so, could i operate
> ApplicationState in them?
>
> Thanks
> Andrey Larionov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Hello,
I can't answer the question on best practise but the wiki has examples
to create authorization with Acegi/Spring Security. You might use this
as inspiration.
You talk about IP. There is no guaranty that the same user has the same
IP in repeated requests. If the user sits behind a proxy cluster, the IP
might change.
For enterprise security, you might have a look at OWASP ESAPI security
as well.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org