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.
smime.p7s
Description: S/MIME Cryptographic Signature
