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
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
> On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni
> wrote:
> > Il 02/01/2010 2
On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni
wrote:
> Il 02/01/2010 20:18, Massimo Lusetti ha scritto:
>> On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
>> wrote:
>>
>>> Let's me play the Devil's advocate for a moment...
>>>
>>> ChenilleKit-Access is an example of why the typical new
Il 02/01/2010 20:18, Massimo Lusetti ha scritto:
> On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
> 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
On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni
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 off
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.
>
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 mor
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/3
Em Thu, 31 Dec 2009 09:16:15 -0200, Alessandro Bottoni
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 pl
Em Thu, 31 Dec 2009 08:44:00 -0200, Alessandro Bottoni
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
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
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 gen
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
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,
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
Em Mon, 28 Dec 2009 20:49:09 -0200, Howard 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 @RequiresLog
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 t
17 matches
Mail list logo
