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 <a...@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.
>
>
>
