OH, also, sorry, I have an RFE on my work project for one-session
logins as well. If I make any progress with that I'll let ya know.
On Mon, 21 Feb 2005 08:02:57 -0600, Ray Krueger [EMAIL PROTECTED] wrote:
I don't have a ton of free time either, but count me in Ben...
Where can I find some
This looks very cool - anything to cut down the amount of XML needed for
Acegi Security is a good thing IMO.
I just finished my chapter on security for Spring Live - do you think I
should scrap the old stuff and update it to reflect this new way? If
so, when will 0.8.0 (or will be it 1.0) be
Robert r. Sanders wrote:
While I don't have a huge amount of spare time, I would be glad to
look over any list of tasks you have and see if I could fit any of
them in. I tried to look on the sourceforge site and see if there
were any bug/feature lists but couldn't find any.
Hi Robert
Given
Dmitriy Kopylenko wrote:
Ben,
how about start using JIRA for Acegi release/issue management? I could create
a project for JIRA in Spring JIRA installation. Would it be appropriate, taking
into consideration that Acegi is not the official Spring subproject?
Dmitriy.
Thanks for the offer, but
Carlos Sanchez wrote:
About the syntax, I looked at map, that would suit here, but Spring application context don't allow beans as keys, maybe a lack of
functionality?
Just use a custom PropertyEditor that works at a String level. The
PropertyEditor would identify name/value pairs, and create
To sum up,
I'll create a class called net.sf.acegisecurity.FilterChain, with a property
called filters.
About the syntax, I looked at map, that would suit here, but Spring
application context don't allow beans as keys, maybe a lack of
functionality?
If we use this one we lose validation, so
Ray Krueger wrote:
I like the idea as well, my only question is (and I've been wondering
this for a while), why do we target the class and not the bean name?
init-param
param-nametargetClass/param-name
param-valuenet.sf.acegisecurity.FilterChain/param-value
/init-param
Instead of...
init-param
This idea looks good to me.
Regards,
Dmitriy.
- Original Message -
From: Carlos Sanchez [EMAIL PROTECTED]
Date: Sunday, January 23, 2005 7:59 am
Subject: [Acegisecurity-developer] Reducing the number of filters needed in
web.xml
Hi,
I think this was already discussed but I wasn't
I think they're is a more elegant and intuitive way to do this.
I also think this a good idea,it would be good to have a more elegant
syntax though,
perhaps you might also consider the following.
snip --
And configure the chain of filters in the application context, something like
bean
bryan ( [EMAIL PROTECTED]) wrote:
bean id=filterChain class=net.sf.acegisecurity.FilterChain
property name=filters
value
channelProcessingFilter=/*
authenticationProcessingFilter=/*
basicProcessingFilter=/*
sessionIntegrationFilter=/*
+1 to this
-Scott
Shishir K. Singh wrote:
+1 to it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan ( [EMAIL
PROTECTED])
Sent: Sunday, January 23, 2005 11:52 AM
To: acegisecurity-developer@lists.sourceforge.net
Subject: Re:
+1
regards,
--
Ricardo
Ben Alex wrote:
bryan ( [EMAIL PROTECTED]) wrote:
bean id=filterChain class=net.sf.acegisecurity.FilterChain
property name=filters
value
channelProcessingFilter=/*
authenticationProcessingFilter=/*
basicProcessingFilter=/*
I like the idea as well, my only question is (and I've been wondering
this for a while), why do we target the class and not the bean name?
init-param
param-nametargetClass/param-name
param-valuenet.sf.acegisecurity.FilterChain/param-value
/init-param
Instead of...
init-param
13 matches
Mail list logo
