You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard <hl...@gmail.com> on 2009/12/28 23:49:09 UTC
[Tapestry Central] Securing Tapestry pages with Annotations, Part 1
This subject still keeps coming up on the mailing list and I thought
I'd show a little bit about how I tackle this problem generally. People
have been asking for a single solution to handling security ... but I
don't see any single solution satisfying even the majority of projects?
Why? There are too many variables. For example, are you using LDAP,
OpenAuth or some ad-hoc user registry (in your database)? Are pages
accessible by default, or in-accessible? Are you using role-based
security? How do you represent roles then? Creating a single solution
that's pluggable enough for all these possibilities seems like an
insurmountable challenge ... but perhaps we can come up with a toolkit
so that you can assemble your own custom solution (more on that later).
One approach to security could be to define a base class,
ProtectedPage, that enforced the basic rules (you must be logged in to
use this page). You can accomplish such a thing using the activate
event handler ... but I find such an approach clumsy. Anytime you can
avoid inheritance, you'll find your code easier to understand, easier
to manage, easier to test and easier to evolve.
Instead, let's pursue a more declarative approach, where we use an
annotation to mark pages that require that the user be logged in. We'll
start with these ground rules:
- Pages are freely accessible by anyone, unless they have
a @RequiresLogin annotation
- Any static resource (in the web context directory) is accessible to
anybody
- There's already some kind of UserAuthentication service that knows if
the user is currently logged in or not, and (if logged in) who they
are, as a User object
So, we need to define a RequiresLogin annotation, and we need to
enforce it, by preventing any access to the page unless the user is
logged in.
That poses a challenge: how do you get "inside" Tapestry to enforce
this annotation? What you really want to do is "slip in" a little bit
of your code into existing Tapestry code ... the code that analyzes the
incoming request, determines what type of request it is (a page render
request vs. a component event request), and ultimately starts calling
into the page code to do the work.
This is a great example of the central design of Tapestry and it's IoC
container: to natively supporting this kind of extensibility. Through
the use of service configurations it's possible to do exactly that:
slip a piece of code into the middle of that default Tapestry code. The
trick is to identify where. This image gives a rough map to how
Tapestry handles incoming requests:
In fact, there's a specific place for this kind of extension: the
ComponentRequestHandler pipeline service1. As a pipeline service,
ComponentRequestHandler has a configuration of filters, and adding a
filter to this pipeline is just what we need. Defining the Annotation
First, lets define our annotation:
@Target( {
ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented
public @interface RequiresLogin { }
This annotation is designed to be placed on a page class to indicate
that the user must be logged in to access the page. The retention
policy is important here: it needs to be visible at runtime for our
runtime code to see it and act on its presence.
An annotation by itself does nothing ... we need the code that checks
for the annotation. Creating a ComponentRequestFilter
Filters for the ComponentRequestHandler pipeline are instances of the
interface ComponentRequestFilter:
/** * Filter interface for {@link
org.apache.tapestry5.services.ComponentRequestHandler}. */ public
interface ComponentRequestFilter { /** * Handler for a component action
request which will trigger an event on a component and use the return
value to * send a response to the client (typically, a redirect to a
page render URL). * * @param parameters defining the request * @param
handler next handler in the pipeline */ void
handleComponentEvent(ComponentEventRequestParameters parameters,
ComponentRequestHandler handler) throws IOException; /** * Invoked to
activate and render a page. In certain cases, based on values returned
when activating the page, a * {@link
org.apache.tapestry5.services.ComponentEventResultProcessor} may be
used to send an alternate response * (typically, a
redirect). * * @param parameters defines the page name and activation
context * @param handler next handler in the pipeline */ void
handlePageRender(PageRenderRequestParameters parameters,
ComponentRequestHandler handler) throws IOException; }
Our implementation of this filter will check the page referenced in the
request to see if it has the annotation. If the annotation is present
and the user has not yet logged in, we'll redirect to the Login page.
When a redirect is not necessary, we delegate to the next handler in
the pipeline2
public class RequiresLoginFilter implements ComponentRequestFilter {
private final PageRenderLinkSource renderLinkSource; private final
ComponentSource componentSource; private final Response response;
private final AuthenticationService authService; public
PageAccessFilter(PageRenderLinkSource renderLinkSource, ComponentSource
componentSource, Response response, AuthenticationService authService)
{ this.renderLinkSource = renderLinkSource; this.componentSource =
componentSource; this.response = response; this.authService =
authService; } public void handleComponentEvent(
ComponentEventRequestParameters parameters, ComponentRequestHandler
handler) throws IOException { if
(dispatchedToLoginPage(parameters.getActivePageName())) { return; }
handler.handleComponentEvent(parameters); } public void
handlePageRender(PageRenderRequestParameters parameters,
ComponentRequestHandler handler) throws IOException { if
(dispatchedToLoginPage(parameters.getLogicalPageName())) { return; }
handler.handlePageRender(parameters); } private boolean
dispatchedToLoginPage(String pageName) throws IOException { if
(authService.isLoggedIn()) { return false; } Component page =
componentSource.getPage(pageName); if (!
page.getClass().isAnnotationPresent(RequiresLogin.class)) { return
false; } Link link = renderLinkSource.createPageRenderLink("Login");
response.sendRedirect(link); return true; } }
The above code makes a bunch of assumptions and simplifications. First,
it assumes the name of the page to redirect to is "Login". It also
doesn't try to capture any part of the incoming request to allow the
application to continue after the user logs in. Finally, the
AuthenticationService is not part of Tapestry ... it is something
specific to the application.
You'll notice that the dependencies (PageRenderLinkSource, etc.) are
injected through constructor parameters and then stored in final
fields. This is the preferred, if more verbose approach. We could also
have used no constructor, a non-final fields with an @Inject annotation
(it's largely a style choice, though constructor injection with final
fields is more guaranteed to be fully thread safe).
The class on its own is not enough, however: we have to get Tapestry to
actually use this class. Contributing the Filter
The last part of this is hooking the above code into the flow. This is
done by making a contribution to the ComponentEventHandler service's
configuration.
Service contributions are implemented as methods of a Tapestry module
class, such as AppModule:
public static void contributeComponentRequestHandler(
OrderedConfiguration configuration) {
configuration.addInstance("RequiresLogin", RequiresLoginFilter.class); }
Contributing modules contribute into an OrderedConfiguration: after all
modules have had a chance to contribute, the configuration is converted
into a List that's passed to the service implementation.
The addInstance() method makes it easy to contribute the filter:
Tapestry will look at the class, see the constructor, and inject
dependencies into the filter via the constructor parameters. It's all
very declarative: the code needs the PageRenderLinkSource, so it simply
defines a final field and a constructor parameter ... Tapestry takes
care of the rest.
You might wonder why we need to specify a name ("RequiresLogin") for
the contribution? The answer addresses a somewhat rare but still
important case: multiple contributions to the same configuration that
have some form of interaction. By giving each contribution a unique id,
it's possible to set up ordering rules (such as "contribution 'Foo'
comes after contribution 'Bar'"). Here, there is no need for ordering
because there aren't any other filters (Tapestry provides this service
and configuration, but doesn't make any contributions of its own into
it). Improvements and Conclusions
This is just a first pass at security. For my clients, I've built more
elaborate solutions, that include capturing the page name and
activation context to allow the application to "resume" after the login
is complete, as well as approaches for automatically logging the user
in as needed (via a cookie or other mechanism).
Other improvements would be to restrict access to pages based on some
set of user roles; again, how this is represented both in code and
annotations, and in the data model is quite up for grabs.
My experience with different clients really underscores what a fuzzy
world security can be: there are so many options for how you represent,
identify and authenticate the user. Even basic decisions are
underpinnings are subject to interpretation; for example, one of my
clients wants all pages to require login unless a specific annotation
is found. Perhaps over time enough of these use cases can be worked out
to build the toolkit I mentioned earlier.
Even so, the amount of code to build a solid, custom security
implementation is still quite small ... though the trick, as always, is
writing just the write code and hooking it into Tapestry in just the
right way.
I expect to follow up this article with part 2, which will expand on
the solution a bit more, addressing some more of the real world
constraints my customers demand. Stay tuned!
1 In fact, this service and pipeline were created in Tapestry 5.1
specifically to address this use case. In Tapestry 5.0, this approach
required two very similar filter contributions to two similar pipelines.
2 If there are multiple filters, you'd think that you'd delegate to the
next filter. Actually you do, but Tapestry provides a bridge: a wrapper
around the filter that uses the main interface for the service. In this
way, each filter delegates to either the next filter, or the terminator
(the service implementation after all filters) in a uniform manner.
More details about this are in the pipeline documentation.
--
Posted By Howard to Tapestry Central at 12/28/2009 02:49:00 PM
Re: Generic Graph component
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Mar 12, 2010 at 12:12 AM, Greg Pagendam-Turner
<gr...@liftyourgame.com> wrote:
> Might be a good component to add to one of the libraries such as Chenille
> Kit.
There could be one... and maybe you could fire an issue with a patch
on chenillekit issues tracking.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Generic Graph component
Posted by Greg Pagendam-Turner <gr...@liftyourgame.com>.
Hi Guys,
I've added a new article to the T5 wiki about how to create a generic
graph component that allows you to pass in a JFreeChart object so you
can create any chart.
http://wiki.apache.org/tapestry/Tapestry5HowToCreateGenericGraphComponent
Might be a good component to add to one of the libraries such as
Chenille Kit.
Regards,
Greg.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi,
I found this solution to the security elegant: simply putting a
@RequiresLogin in the page to be protected and let the
ComponentRequestFilter checks the annotation in the page. now if I need
something else, say @ReqiresOwner, say I'd allow the owner of inbox to go to
a Inbox page, I can pass the instance of Inbox page to authService：
if ( page.getClass().isAnnotationPresent(RequiresOwner.class)) {
if (!authService.checkPageOwner(page)) {
return false;
}
}
And condition to check if a logged in user is the owner of the said page
depends on situation, most of time it depends on the activation context
which might be the user, or some objects belong to the user, what will be a
generic way to take care of this situations? Thanks,
Angelo
Howard Lewis Ship wrote:
>
> This subject still keeps coming up on the mailing list and I thought
> I'd show a little bit about how I tackle this problem generally. People
> have been asking for a single solution to handling security ... but I
> don't see any single solution satisfying even the majority of projects?
> Why? There are too many variables. For example, are you using LDAP,
> OpenAuth or some ad-hoc user registry (in your database)? Are pages
> accessible by default, or in-accessible? Are you using role-based
> security? How do you represent roles then? Creating a single solution
> that's pluggable enough for all these possibilities seems like an
> insurmountable challenge ... but perhaps we can come up with a toolkit
> so that you can assemble your own custom solution (more on that later).
> One approach to security could be to define a base class,
> ProtectedPage, that enforced the basic rules (you must be logged in to
> use this page). You can accomplish such a thing using the activate
> event handler ... but I find such an approach clumsy. Anytime you can
> avoid inheritance, you'll find your code easier to understand, easier
> to manage, easier to test and easier to evolve.
> Instead, let's pursue a more declarative approach, where we use an
> annotation to mark pages that require that the user be logged in. We'll
> start with these ground rules:
> - Pages are freely accessible by anyone, unless they have
> a @RequiresLogin annotation
> - Any static resource (in the web context directory) is accessible to
> anybody
> - There's already some kind of UserAuthentication service that knows if
> the user is currently logged in or not, and (if logged in) who they
> are, as a User object
> So, we need to define a RequiresLogin annotation, and we need to
> enforce it, by preventing any access to the page unless the user is
> logged in.
> That poses a challenge: how do you get "inside" Tapestry to enforce
> this annotation? What you really want to do is "slip in" a little bit
> of your code into existing Tapestry code ... the code that analyzes the
> incoming request, determines what type of request it is (a page render
> request vs. a component event request), and ultimately starts calling
> into the page code to do the work.
> This is a great example of the central design of Tapestry and it's IoC
> container: to natively supporting this kind of extensibility. Through
> the use of service configurations it's possible to do exactly that:
> slip a piece of code into the middle of that default Tapestry code. The
> trick is to identify where. This image gives a rough map to how
> Tapestry handles incoming requests:
>
> In fact, there's a specific place for this kind of extension: the
> ComponentRequestHandler pipeline service1. As a pipeline service,
> ComponentRequestHandler has a configuration of filters, and adding a
> filter to this pipeline is just what we need. Defining the Annotation
> First, lets define our annotation:
>
> @Target( {
> ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented
> public @interface RequiresLogin { }
>
> This annotation is designed to be placed on a page class to indicate
> that the user must be logged in to access the page. The retention
> policy is important here: it needs to be visible at runtime for our
> runtime code to see it and act on its presence.
> An annotation by itself does nothing ... we need the code that checks
> for the annotation. Creating a ComponentRequestFilter
> Filters for the ComponentRequestHandler pipeline are instances of the
> interface ComponentRequestFilter:
> /** * Filter interface for {@link
> org.apache.tapestry5.services.ComponentRequestHandler}. */ public
> interface ComponentRequestFilter { /** * Handler for a component action
> request which will trigger an event on a component and use the return
> value to * send a response to the client (typically, a redirect to a
> page render URL). * * @param parameters defining the request * @param
> handler next handler in the pipeline */ void
> handleComponentEvent(ComponentEventRequestParameters parameters,
> ComponentRequestHandler handler) throws IOException; /** * Invoked to
> activate and render a page. In certain cases, based on values returned
> when activating the page, a * {@link
> org.apache.tapestry5.services.ComponentEventResultProcessor} may be
> used to send an alternate response * (typically, a
> redirect). * * @param parameters defines the page name and activation
> context * @param handler next handler in the pipeline */ void
> handlePageRender(PageRenderRequestParameters parameters,
> ComponentRequestHandler handler) throws IOException; }
>
> Our implementation of this filter will check the page referenced in the
> request to see if it has the annotation. If the annotation is present
> and the user has not yet logged in, we'll redirect to the Login page.
> When a redirect is not necessary, we delegate to the next handler in
> the pipeline2
> public class RequiresLoginFilter implements ComponentRequestFilter {
> private final PageRenderLinkSource renderLinkSource; private final
> ComponentSource componentSource; private final Response response;
> private final AuthenticationService authService; public
> PageAccessFilter(PageRenderLinkSource renderLinkSource, ComponentSource
> componentSource, Response response, AuthenticationService authService)
> { this.renderLinkSource = renderLinkSource; this.componentSource =
> componentSource; this.response = response; this.authService =
> authService; } public void handleComponentEvent(
> ComponentEventRequestParameters parameters, ComponentRequestHandler
> handler) throws IOException { if
> (dispatchedToLoginPage(parameters.getActivePageName())) { return; }
> handler.handleComponentEvent(parameters); } public void
> handlePageRender(PageRenderRequestParameters parameters,
> ComponentRequestHandler handler) throws IOException { if
> (dispatchedToLoginPage(parameters.getLogicalPageName())) { return; }
> handler.handlePageRender(parameters); } private boolean
> dispatchedToLoginPage(String pageName) throws IOException { if
> (authService.isLoggedIn()) { return false; } Component page =
> componentSource.getPage(pageName); if (!
> page.getClass().isAnnotationPresent(RequiresLogin.class)) { return
> false; } Link link = renderLinkSource.createPageRenderLink("Login");
> response.sendRedirect(link); return true; } }
>
> The above code makes a bunch of assumptions and simplifications. First,
> it assumes the name of the page to redirect to is "Login". It also
> doesn't try to capture any part of the incoming request to allow the
> application to continue after the user logs in. Finally, the
> AuthenticationService is not part of Tapestry ... it is something
> specific to the application.
> You'll notice that the dependencies (PageRenderLinkSource, etc.) are
> injected through constructor parameters and then stored in final
> fields. This is the preferred, if more verbose approach. We could also
> have used no constructor, a non-final fields with an @Inject annotation
> (it's largely a style choice, though constructor injection with final
> fields is more guaranteed to be fully thread safe).
> The class on its own is not enough, however: we have to get Tapestry to
> actually use this class. Contributing the Filter
> The last part of this is hooking the above code into the flow. This is
> done by making a contribution to the ComponentEventHandler service's
> configuration.
> Service contributions are implemented as methods of a Tapestry module
> class, such as AppModule:
> public static void contributeComponentRequestHandler(
> OrderedConfiguration configuration) {
> configuration.addInstance("RequiresLogin", RequiresLoginFilter.class); }
>
> Contributing modules contribute into an OrderedConfiguration: after all
> modules have had a chance to contribute, the configuration is converted
> into a List that's passed to the service implementation.
> The addInstance() method makes it easy to contribute the filter:
> Tapestry will look at the class, see the constructor, and inject
> dependencies into the filter via the constructor parameters. It's all
> very declarative: the code needs the PageRenderLinkSource, so it simply
> defines a final field and a constructor parameter ... Tapestry takes
> care of the rest.
> You might wonder why we need to specify a name ("RequiresLogin") for
> the contribution? The answer addresses a somewhat rare but still
> important case: multiple contributions to the same configuration that
> have some form of interaction. By giving each contribution a unique id,
> it's possible to set up ordering rules (such as "contribution 'Foo'
> comes after contribution 'Bar'"). Here, there is no need for ordering
> because there aren't any other filters (Tapestry provides this service
> and configuration, but doesn't make any contributions of its own into
> it). Improvements and Conclusions
> This is just a first pass at security. For my clients, I've built more
> elaborate solutions, that include capturing the page name and
> activation context to allow the application to "resume" after the login
> is complete, as well as approaches for automatically logging the user
> in as needed (via a cookie or other mechanism).
> Other improvements would be to restrict access to pages based on some
> set of user roles; again, how this is represented both in code and
> annotations, and in the data model is quite up for grabs.
> My experience with different clients really underscores what a fuzzy
> world security can be: there are so many options for how you represent,
> identify and authenticate the user. Even basic decisions are
> underpinnings are subject to interpretation; for example, one of my
> clients wants all pages to require login unless a specific annotation
> is found. Perhaps over time enough of these use cases can be worked out
> to build the toolkit I mentioned earlier.
> Even so, the amount of code to build a solid, custom security
> implementation is still quite small ... though the trick, as always, is
> writing just the write code and hooking it into Tapestry in just the
> right way.
> I expect to follow up this article with part 2, which will expand on
> the solution a bit more, addressing some more of the real world
> constraints my customers demand. Stay tuned!
> 1 In fact, this service and pipeline were created in Tapestry 5.1
> specifically to address this use case. In Tapestry 5.0, this approach
> required two very similar filter contributions to two similar pipelines.
> 2 If there are multiple filters, you'd think that you'd delegate to the
> next filter. Actually you do, but Tapestry provides a bridge: a wrapper
> around the filter that uses the main interface for the service. In this
> way, each filter delegates to either the next filter, or the terminator
> (the service implementation after all filters) in a uniform manner.
> More details about this are in the pipeline documentation.
>
> --
> Posted By Howard to Tapestry Central at 12/28/2009 02:49:00 PM
>
--
View this message in context: http://old.nabble.com/-Tapestry-Central--Securing-Tapestry-pages-with-Annotations%2C-Part-1-tp26949008p27714327.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: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 28 Dec 2009 20:49:09 -0200, Howard <hl...@gmail.com> escreveu:
> Instead, let's pursue a more declarative approach, where we use an
> annotation to mark pages that require that the user be logged in. We'll
> start with these ground rules:
> - Pages are freely accessible by anyone, unless they have
> a @RequiresLogin annotation
That's exactly the approach used in my Tapestry Security package. It's not
released yet nor it has documentation, but I'm already using it in
production for a public Internet website (www.pronutricionista.com.br).
Tapestry Security sources are available for browsing at
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-security/trunk/
and checkout at
https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/tapestry-security/trunk.
There's a @NeedsLoggedInUser annotation that is processed by a Dispatcher.
It throws an AnonymousAccessDeniedException when a not logged in user
attempts to read that page. Tapestry Security is built on top of Generic
Authentication and Generic Authorization, two other packages in the same
repository. Generic Authentication defines User, Permission,
PermissionGroup, and UserGroup classes. There's another annotation,
@NeedsPermission, denies access to unlogged users and logged user that
don't have the need permission(s). Generic Authorization defines a
framework for controlling access to reading, creating, updating, and
removing objects, both at object and class level. Then Tapestry CRUD (even
another package inside the Ars Machina Project) uses them to automatically
secure CRUD pages.
I wish I had the opportunity the document and write unit test for them, so
I could donate them to Tapestry, a project that requires very high quality
code.
Everyone is invited to checkout the code and post opinions and suggestions
in the mailing list or send them to me directly.
> - There's already some kind of UserAuthentication service that knows if
> the user is currently logged in or not, and (if logged in) who they
> are, as a User object
Tapestry Security has an UserService service that does exactly that. Maybe
we could reuse it in Tapestry itself.
> application to continue after the user logs in. Finally, the
> AuthenticationService is not part of Tapestry ... it is something
> specific to the application.
Tapestry could define an AuthenticationService interface and just provide
a dummy one out-of-the-box. Other packages could overwrite the
implementation of this service.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 29/12/2009 12:45, Vangel V. Ajanovski ha scritto:
> +1 from me for putting such article in the official documentation on the
> website, because blogs are (by nature) relevant for a moment in time and
> if it's put in the official documentation one would have to check and
> "sign" that this works on every new release.
And +1 for me, as well. Such info should stay in plain sight in the
"HowTo" section of the wiki and/or in the official docu.
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"If man hasn't discovered something that he will die for, he isn't fit
to live."
-- Martin Luther King
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 31 Dec 2009 09:16:15 -0200, Alessandro Bottoni
<al...@gmail.com> escreveu:
> Il 29/12/2009 21:32, Alex Kotchnev ha scritto:
>> approach. As Thiago already mentioned, there are at least a few more
>> solutions that attempt to provide this (e.g. Thiago's own,
>> chenillekit-access, and a bunch more).
>
> Let's me play the Devil's advocate for a moment...
I guess Alex suggested to start the development of a Tapestry security
package based on some package that already exists, not adopting them as
part of the Tapestry project as they are now. We all agree that
documentation is key and should be improved.
> Moreover, in many cases it would be very hard to convince the project
> leader or the end user to accept a (sorry Thiago ....) not-canonical,
> little known, little documented, maybe-risky library like this one.
I never suggested that someone should use a little documented package, so
I don't know why you're apologizing to me. :)
Little-known library? Unfortunately, Tapestry is not a very well-known
library AFAIK. :(
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by Toby Hobson <to...@googlemail.com>.
Just to add my 2 cents ... imho it's best to build on an exiting framework
like spring-security rather than trying to re-invent the wheel.
acegi/spring-security has great traction in the market and it's very well
documented. Recent versions are becoming much simpler due to sensible
defaults but more esoteric use-cases are still supported.
Toby
2009/12/31 Sven Homburg <ho...@googlemail.com>
> Hi Allesandro,
>
> i totally agree with you.
> The documentation of the ChenilleKit-Modules
> is bad or lacks at some points.
>
> One of our good intentions for 2010 is to
> write more and better docs.
>
>
> with regards
> Sven Homburg
> Founder of the Chenille Kit Project
> http://chenillekit.codehaus.org
>
>
>
>
> 2009/12/31 Alessandro Bottoni <al...@gmail.com>
>
> > Il 29/12/2009 21:32, Alex Kotchnev ha scritto:
> > > approach. As Thiago already mentioned, there are at least a few more
> > > solutions that attempt to provide this (e.g. Thiago's own,
> > > chenillekit-access, and a bunch more).
> >
> > Let's me play the Devil's advocate for a moment...
> >
> > ChenilleKit-Access is an example of why the typical new user (like me)
> > will NOT use such a solution, no matter how good and elegant it could
> > be. The reason is that the ONLY official documentation you can find
> > using Google is the following....
> >
> > <quote>
> > Introduction
> >
> > ChenilleKit Access module sits in between your page processing logic and
> > the client HTTP request, doing so it is able to decide when and how the
> > request can pass through or not.
> >
> > For doing so it needs two different steps. First it put RestrictedWorker
> > into the ComponentClassTranformWorker pipeline, this class is
> > responsible to read the annotation class and store various meta
> > information needed by AccessValidator. Second it put two Dispatcher into
> > two different pipelines for intercepting page render and component event
> > action requests to check if they're directed to restricted class/events
> > and to apply the needed constraints.
> > </quote>
> >
> > I'm sorry but I have to say that many (or most?) new users will not have
> > neither the time nor the patience to study the JavaDoc or the source
> > code just to figure out how to use this (or any other) library, no
> > matter how simple it can be.
> >
> > Moreover, in many cases it would be very hard to convince the project
> > leader or the end user to accept a (sorry Thiago ....) not-canonical,
> > little known, little documented, maybe-risky library like this one.
> >
> > For what regards me, for example, I would be forced to look for a
> > widely-recognized, well-tested, well-documented, standard module, inside
> > or outside the Tapestry world (Acegi?) or, as an alternative, to
> > demonstrate that ChenilleKit is the right tool for the task at hand
> > (being ready to pay for any possible error about my judgment...).
> >
> > Just the voice of the Devil, anyway... ;-)
> >
> > PS: Yes, I'm aware of this article:
> > http://www.equanda.org/templates/login.html .
> >
> > --
> >
> > Alessandro Bottoni
> > Website: http://www.alessandrobottoni.it/
> >
> > "They say if you play a Microsoft CD backwards,
> > you hear satanic messages.
> > That's nothing, cause if you play it forwards,
> > it installs Windows."
> > -- Unknown
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by Sven Homburg <ho...@googlemail.com>.
Hi Allesandro,
i totally agree with you.
The documentation of the ChenilleKit-Modules
is bad or lacks at some points.
One of our good intentions for 2010 is to
write more and better docs.
with regards
Sven Homburg
Founder of the Chenille Kit Project
http://chenillekit.codehaus.org
2009/12/31 Alessandro Bottoni <al...@gmail.com>
> Il 29/12/2009 21:32, Alex Kotchnev ha scritto:
> > approach. As Thiago already mentioned, there are at least a few more
> > solutions that attempt to provide this (e.g. Thiago's own,
> > chenillekit-access, and a bunch more).
>
> Let's me play the Devil's advocate for a moment...
>
> ChenilleKit-Access is an example of why the typical new user (like me)
> will NOT use such a solution, no matter how good and elegant it could
> be. The reason is that the ONLY official documentation you can find
> using Google is the following....
>
> <quote>
> Introduction
>
> ChenilleKit Access module sits in between your page processing logic and
> the client HTTP request, doing so it is able to decide when and how the
> request can pass through or not.
>
> For doing so it needs two different steps. First it put RestrictedWorker
> into the ComponentClassTranformWorker pipeline, this class is
> responsible to read the annotation class and store various meta
> information needed by AccessValidator. Second it put two Dispatcher into
> two different pipelines for intercepting page render and component event
> action requests to check if they're directed to restricted class/events
> and to apply the needed constraints.
> </quote>
>
> I'm sorry but I have to say that many (or most?) new users will not have
> neither the time nor the patience to study the JavaDoc or the source
> code just to figure out how to use this (or any other) library, no
> matter how simple it can be.
>
> Moreover, in many cases it would be very hard to convince the project
> leader or the end user to accept a (sorry Thiago ....) not-canonical,
> little known, little documented, maybe-risky library like this one.
>
> For what regards me, for example, I would be forced to look for a
> widely-recognized, well-tested, well-documented, standard module, inside
> or outside the Tapestry world (Acegi?) or, as an alternative, to
> demonstrate that ChenilleKit is the right tool for the task at hand
> (being ready to pay for any possible error about my judgment...).
>
> Just the voice of the Devil, anyway... ;-)
>
> PS: Yes, I'm aware of this article:
> http://www.equanda.org/templates/login.html .
>
> --
>
> Alessandro Bottoni
> Website: http://www.alessandrobottoni.it/
>
> "They say if you play a Microsoft CD backwards,
> you hear satanic messages.
> That's nothing, cause if you play it forwards,
> it installs Windows."
> -- Unknown
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by Sven Homburg <ho...@googlemail.com>.
sometimes i am wondered about people,
the hopes, that they "learn" tapestry at their REM phase.
with regards
Sven Homburg
Founder of the Chenille Kit Project
http://chenillekit.codehaus.org
2010/1/2 cleverpig <gr...@gmail.com>
> On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni
> <al...@gmail.com> wrote:
> > Il 02/01/2010 20:18, Massimo Lusetti ha scritto:
> >> On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
> >> <al...@gmail.com> wrote:
> >>
> >>> Let's me play the Devil's advocate for a moment...
> >>>
> >>> ChenilleKit-Access is an example of why the typical new user (like me)
> >>> will NOT use such a solution, no matter how good and elegant it could
> >>> be. The reason is that the ONLY official documentation you can find
> >>> using Google is the following....
> >>
> >> Unfortunately i can't see any code nor docs from you.
> >
> > Massimo, of course you are right when you underline this but...
> >
> > "Let's me play the Devil's advocate for a moment..."
> >
> > :-)
> >
> > I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm
> > just trying to understand why Tapestry does not have the same level of
> > appreciation by the large public as Wicket, despite its evident
> > technical superiority.
> >
> > I'll be happy to contribute some code/docu when I'll be able to write
> > it. Of course, the less docu I find, the less code and docu I'll be able
> > to write in the short/medium term. :-)
>
> tapestry document are really less,and not fit with the friends from
> non-english country.
> code example were a little no practical .. it's my advice...
> so we should do more and complain less..
>
> >
> > Cheers
> > --
> >
> > Alessandro Bottoni
> > Website: http://www.alessandrobottoni.it/
> >
> > "Some subjects are so serious that one can only joke about them."
> > -- Niels Bohr
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
>
> --
> cleverpig(Dan)
> Location: Beijing
> Address: Room 4018,No.A2 South Avenue Fuxingmen Beijing,P.R.China
> Zipcode: 100031
> MSN: great_liudan@hotmail.com
> QQ: 149291732
> Skype: cleverpigatmatrix
> Facebook ID:cleverpig
> Blog: www.cleverpig.name
> Tags: del.icio.us/cleverpig
> Twitter: twitter.com/cleverpig
> 新浪微博: t.sina.com.cn/cleverpig
> Organization: www.beijing-open-party.org
> Organ@Facebook: http://www.facebook.com/group.php?gid=8159558294
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by cleverpig <gr...@gmail.com>.
On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni
<al...@gmail.com> wrote:
> Il 02/01/2010 20:18, Massimo Lusetti ha scritto:
>> On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
>> <al...@gmail.com> wrote:
>>
>>> Let's me play the Devil's advocate for a moment...
>>>
>>> ChenilleKit-Access is an example of why the typical new user (like me)
>>> will NOT use such a solution, no matter how good and elegant it could
>>> be. The reason is that the ONLY official documentation you can find
>>> using Google is the following....
>>
>> Unfortunately i can't see any code nor docs from you.
>
> Massimo, of course you are right when you underline this but...
>
> "Let's me play the Devil's advocate for a moment..."
>
> :-)
>
> I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm
> just trying to understand why Tapestry does not have the same level of
> appreciation by the large public as Wicket, despite its evident
> technical superiority.
>
> I'll be happy to contribute some code/docu when I'll be able to write
> it. Of course, the less docu I find, the less code and docu I'll be able
> to write in the short/medium term. :-)
tapestry document are really less,and not fit with the friends from
non-english country.
code example were a little no practical .. it's my advice...
so we should do more and complain less..
>
> Cheers
> --
>
> Alessandro Bottoni
> Website: http://www.alessandrobottoni.it/
>
> "Some subjects are so serious that one can only joke about them."
> -- Niels Bohr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
cleverpig(Dan)
Location: Beijing
Address: Room 4018,No.A2 South Avenue Fuxingmen Beijing,P.R.China
Zipcode: 100031
MSN: great_liudan@hotmail.com
QQ: 149291732
Skype: cleverpigatmatrix
Facebook ID:cleverpig
Blog: www.cleverpig.name
Tags: del.icio.us/cleverpig
Twitter: twitter.com/cleverpig
新浪微博: t.sina.com.cn/cleverpig
Organization: www.beijing-open-party.org
Organ@Facebook: http://www.facebook.com/group.php?gid=8159558294
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 02/01/2010 20:18, Massimo Lusetti ha scritto:
> On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
> <al...@gmail.com> wrote:
>
>> Let's me play the Devil's advocate for a moment...
>>
>> ChenilleKit-Access is an example of why the typical new user (like me)
>> will NOT use such a solution, no matter how good and elegant it could
>> be. The reason is that the ONLY official documentation you can find
>> using Google is the following....
>
> Unfortunately i can't see any code nor docs from you.
Massimo, of course you are right when you underline this but...
"Let's me play the Devil's advocate for a moment..."
:-)
I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm
just trying to understand why Tapestry does not have the same level of
appreciation by the large public as Wicket, despite its evident
technical superiority.
I'll be happy to contribute some code/docu when I'll be able to write
it. Of course, the less docu I find, the less code and docu I'll be able
to write in the short/medium term. :-)
Cheers
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"Some subjects are so serious that one can only joke about them."
-- Niels Bohr
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
<al...@gmail.com> wrote:
> Let's me play the Devil's advocate for a moment...
>
> ChenilleKit-Access is an example of why the typical new user (like me)
> will NOT use such a solution, no matter how good and elegant it could
> be. The reason is that the ONLY official documentation you can find
> using Google is the following....
Unfortunately i can't see any code nor docs from you.
Cheers
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 29/12/2009 21:32, Alex Kotchnev ha scritto:
> approach. As Thiago already mentioned, there are at least a few more
> solutions that attempt to provide this (e.g. Thiago's own,
> chenillekit-access, and a bunch more).
Let's me play the Devil's advocate for a moment...
ChenilleKit-Access is an example of why the typical new user (like me)
will NOT use such a solution, no matter how good and elegant it could
be. The reason is that the ONLY official documentation you can find
using Google is the following....
<quote>
Introduction
ChenilleKit Access module sits in between your page processing logic and
the client HTTP request, doing so it is able to decide when and how the
request can pass through or not.
For doing so it needs two different steps. First it put RestrictedWorker
into the ComponentClassTranformWorker pipeline, this class is
responsible to read the annotation class and store various meta
information needed by AccessValidator. Second it put two Dispatcher into
two different pipelines for intercepting page render and component event
action requests to check if they're directed to restricted class/events
and to apply the needed constraints.
</quote>
I'm sorry but I have to say that many (or most?) new users will not have
neither the time nor the patience to study the JavaDoc or the source
code just to figure out how to use this (or any other) library, no
matter how simple it can be.
Moreover, in many cases it would be very hard to convince the project
leader or the end user to accept a (sorry Thiago ....) not-canonical,
little known, little documented, maybe-risky library like this one.
For what regards me, for example, I would be forced to look for a
widely-recognized, well-tested, well-documented, standard module, inside
or outside the Tapestry world (Acegi?) or, as an alternative, to
demonstrate that ChenilleKit is the right tool for the task at hand
(being ready to pay for any possible error about my judgment...).
Just the voice of the Devil, anyway... ;-)
PS: Yes, I'm aware of this article:
http://www.equanda.org/templates/login.html .
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"They say if you play a Microsoft CD backwards,
you hear satanic messages.
That's nothing, cause if you play it forwards,
it installs Windows."
-- Unknown
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by "Vangel V. Ajanovski" <aj...@ii.edu.mk>.
On 31.12.2009 11:44, Alessandro Bottoni wrote:
> 2) An enterprise-level module, like Spring Security. This solution
> should have to be flexible and extendible. It should be able to deal
> with LDAP, OpenID, JASIG CAS and other providers. It would be used for
> complex, enterprise-level apps.
>
When you mention CAS, do you know that by using it you can in fact use
both JDBC, LDAP, Active Directory, Radius, JAAS, Kerberos behind it all
at the same time..
CAS can authenticate your users from many sources and they will see only
a single login page. I have pretty positive experience with JASIG CAS
and we have been using it for 4 years now. We use it for single-sign-on
accross several applications (uPortal, Moodle, Trac, our Course
Enrollment project based on Tapestry, another ASP.Net project, few other
PHP apps etc).
Why we decided on CAS. The userbase is mostly US universities with tens
of thousands of students. If they trust it to keep users in or out of
their services, why wouldn't we?
1. CAS has a service, which is a relatively small java web app (13MB
war) that presents a login screen and redirects to your application if
the user is authenticated. Very easy to configure. The setup is very
very easy (XML based) and there are many configuration examples on the
web and I was able to set it in under Tomcat and configure to connect to
two active directory domains in just half an hour. So users from both
domains can use my application and any other application that will be
casified.
2. How to use it in the app?
a. In your app you include a CAS client that checks the service if any
user is logged in and what is the name of the user. This is again
simple, you just read the username via some method from the client classes.
b. If you don't like to put the client in your app, you can set it as a
filter on the web server (in web.xml) to listen to several paths. So on
each request if the user is logged in, a session variable will be set
with the validated username.
c. Both ways you get the username and you can then decide what to do
about it.
I think that's simple. Few XML configurations for the CAS service and a
single line of code to get the username in your app.
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 31 Dec 2009 08:44:00 -0200, Alessandro Bottoni
<al...@gmail.com> escreveu:
> 1) A quite basic module, or even a well-documented demo, that just takes
> into account the most common requirements and uses a set of sensible
> defaults. This basic "package" should not have to be extensible or
> flexible.
A demo with this features would be a very good idea.
> 2) An enterprise-level module, like Spring Security. This solution
> should have to be flexible and extendible. It should be able to deal
> with LDAP, OpenID, JASIG CAS and other providers. It would be used for
> complex, enterprise-level apps.
Re-implement something like Spring Security is not feasible, IMHO. It
would need people who know a lot about security, and Tapestry is a Web
framework. In addition, that's an awful lot of code to write and, AFAIK,
very few projects use these security providers (besides OpenID). We should
focus on what will be useful for the most people.
I don't think using Spring Security the Tapestry security module because
it forces the use of Spring. I still need to take a look at
JSecurity/Apache Shiro, but I guess it would fill this need better.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 29/12/2009 21:32, Alex Kotchnev ha scritto:
> chenillekit-access, and a bunch more). As much as people have a tendency to
> complain that spring security is too complicated, it seems that any other
> solution (e.g. based on T5 IoC) that attempts to provide the same level of
> flexibility and generality will eventually end up with similar complexity (
> and will most likely never have the mind & market share of spring security).
> Thus, it seems to me that the effort to provide a "new" framework to do all
> of this is somewhat futile.
Actually, maybe there is a need for TWO different solutions:
1) A quite basic module, or even a well-documented demo, that just takes
into account the most common requirements and uses a set of sensible
defaults. This basic "package" should not have to be extensible or
flexible. It should just have to be usable and understandable. It would
be mostly used to study this problem and to see how to solve it in a
Tapestry-like way. It would also be used as a quick&dirty solution for
the most basic applications. IMHO, this solution should be developed
with Tapestry annotations (see:
http://tapestryjava.blogspot.com/2009/12/securing-tapestry-pages-with.html)
and used as a demo of such programming technique, as well.
2) An enterprise-level module, like Spring Security. This solution
should have to be flexible and extendible. It should be able to deal
with LDAP, OpenID, JASIG CAS and other providers. It would be used for
complex, enterprise-level apps.
> An alternative approach (which seems to be quite successful in Grails
> land) seems to be to provide integration & simplification w/ existing
> security frameworks that already have all of the flexibility (and
> complexity) that you talk about . For example. in Grails using the spring
> security plugin comes down to installing the plugin and annotating your
> controllers w/ Roles - it certainly reduces the number of available options
> (thus making it less flexible) but the ease of getting started with it is
> quite attractive .
This would a very good solution for this problem and I vote for it.
Despite this, it would be very little "tapestrystic" (it rhimes with
"pythonistic")... I mean: it would miss the apportunity to contribute in
making a more componentized, elegant working environment for all of us.
> If the desire is to provide a pure T5 based solution,
> why not take one of the existing security modules (e.g. chenillekit-access)
> and analyze its approach and improve it instead of starting from scratch
> (and use the forum as an opportunity to improve & extend the same existing
> component) ?
This approach is exactly what I would expect for the "enterprise-level
module" I described above (case 2). It could/should be something like
ACEGI or Swarm/Wasp and it should be very standardized, quite
extensible/flexible and very well tested. It could be based on
annotations or on other techniques, depending on the judgment of the
developing community. Most likely, it would deserve a separated project.
JM2C
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"Life is a sexually transmitted disease, and it's 100% fatal."
-- Unknown
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part
1
Posted by Alex Kotchnev <ak...@gmail.com>.
Howard,
having looked at the T5-spring-security code (and spring security
itself) I see quite a number of similarities with what you describe as an
approach. As Thiago already mentioned, there are at least a few more
solutions that attempt to provide this (e.g. Thiago's own,
chenillekit-access, and a bunch more). As much as people have a tendency to
complain that spring security is too complicated, it seems that any other
solution (e.g. based on T5 IoC) that attempts to provide the same level of
flexibility and generality will eventually end up with similar complexity (
and will most likely never have the mind & market share of spring security).
Thus, it seems to me that the effort to provide a "new" framework to do all
of this is somewhat futile.
An alternative approach (which seems to be quite successful in Grails
land) seems to be to provide integration & simplification w/ existing
security frameworks that already have all of the flexibility (and
complexity) that you talk about . For example. in Grails using the spring
security plugin comes down to installing the plugin and annotating your
controllers w/ Roles - it certainly reduces the number of available options
(thus making it less flexible) but the ease of getting started with it is
quite attractive . If the desire is to provide a pure T5 based solution,
why not take one of the existing security modules (e.g. chenillekit-access)
and analyze its approach and improve it instead of starting from scratch
(and use the forum as an opportunity to improve & extend the same existing
component) ?
Regards,
Alex K
On Tue, Dec 29, 2009 at 6:45 AM, Vangel V. Ajanovski <aj...@ii.edu.mk> wrote:
> On 28.12.2009 23:49, Howard wrote:
> > Instead, let's pursue a more declarative approach, where we use an
> > annotation to mark pages that require that the user be logged in. We'll
> > start with these ground rules:
> >
> We changed several approaches since the start of our app, and this
> approach is the last we have.
>
> But as Howard discussed many times, such a solution is not fit for
> everyone, and we don't have that special requirements.
> We use this approach only for authorization, while the authentication is
> completely done by JASIG CAS client that sits configured as a filter in
> front of Tapestry.
> In this case, if the visitor is not authenticated, he will never be able
> to get a request thru to tapestry.
> For authorization we have several different page annotations (similar to
> the @RequiresLogin annotation) that we can combine and they tell us the
> groups of users that are allowed to access a page.
> Then a cross check is done in the requesthandler contribution whether
> the annotation on the page corresponds to some of the groups the user is
> member of read from the database.
>
> Before that we had spring-security and i didn't like it, although the
> point of it was that it already supported many type of authentication
> methods. But it turns out we don't need them now, and the change was not
> that big.
>
> The information on how to implement all this was already discussed on
> this mailing list, the wiki and other places and I managed to glue that
> up in our working solution in less than a week working in free time.
> Some of the wiki guides were outdated and hindered the process. With
> such a guide I would have finished in just 1 day.
>
> +1 from me for putting such article in the official documentation on the
> website, because blogs are (by nature) relevant for a moment in time and
> if it's put in the official documentation one would have to check and
> "sign" that this works on every new release.
>
>
>
Re: [Tapestry Central] Securing Tapestry pages with Annotations,
Part 1
Posted by "Vangel V. Ajanovski" <aj...@ii.edu.mk>.
On 28.12.2009 23:49, Howard wrote:
> Instead, let's pursue a more declarative approach, where we use an
> annotation to mark pages that require that the user be logged in. We'll
> start with these ground rules:
>
We changed several approaches since the start of our app, and this
approach is the last we have.
But as Howard discussed many times, such a solution is not fit for
everyone, and we don't have that special requirements.
We use this approach only for authorization, while the authentication is
completely done by JASIG CAS client that sits configured as a filter in
front of Tapestry.
In this case, if the visitor is not authenticated, he will never be able
to get a request thru to tapestry.
For authorization we have several different page annotations (similar to
the @RequiresLogin annotation) that we can combine and they tell us the
groups of users that are allowed to access a page.
Then a cross check is done in the requesthandler contribution whether
the annotation on the page corresponds to some of the groups the user is
member of read from the database.
Before that we had spring-security and i didn't like it, although the
point of it was that it already supported many type of authentication
methods. But it turns out we don't need them now, and the change was not
that big.
The information on how to implement all this was already discussed on
this mailing list, the wiki and other places and I managed to glue that
up in our working solution in less than a week working in free time.
Some of the wiki guides were outdated and hindered the process. With
such a guide I would have finished in just 1 day.
+1 from me for putting such article in the official documentation on the
website, because blogs are (by nature) relevant for a moment in time and
if it's put in the official documentation one would have to check and
"sign" that this works on every new release.