That's the correct URL for the core,
https://src.springframework.org/svn/spring-security/branches/2.0.x-branch is
the url for the whole branch. There's a SSL certificate mismatch - that's
probably confusing your client. I use Eclipse and it prompted me to keep the
mismatched certificate and
I managed to answer this one myself, by trolling the Internet and
reading the Acegi source. The final answer was to create a
RESTfulDefinitionSource. I used Spring constructor injection to load
in the security patterns:
bean id=filterInvocationInterceptor
Nice work Chris, any chance you could open some Jiras on that?
On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote:
I managed to answer this one myself, by trolling the Internet and reading
the Acegi source. The final answer was to create a RESTfulDefinitionSource.
I used Spring constructor
Done
http://opensource.atlassian.com/projects/spring/browse/SEC-531
Cheers,
-- Chris
On Aug 23, 2007, at 1:44 PM, Chris Berry wrote:
Will do.
It sure would be nice to incorporate this back into Acegi.
IMHO, REST will (or is ;-) supplant all other web service
methodologies. Acegi should
Agreed :)
And thanks!
On 8/23/07, Chris Berry [EMAIL PROTECTED] wrote:
Done
http://opensource.atlassian.com/projects/spring/browse/SEC-531
Cheers,
-- Chris
On Aug 23, 2007, at 1:44 PM, Chris Berry wrote:
Will do.
It sure would be nice to incorporate this back into Acegi.
IMHO, REST will
Greetings,
I am trying to set up Acegi (using HTTP BASIC Auth) for a set of
RESTful web services (implemented using the Atom Publishing Protocol)
And I have the basic setup running.
But REST complicates matters because the exact same URL is used for
reads and writes, with the HTTP method
Unfortunately, this package isn't well suited for extension.
I could extend PathBasedFilterInvocationDefinitionMap
but since it provides no way to access requestMap pathMatcher
I had to duplicate all of that code.
But I could workaround that, what I don't see is how to get around
the
Yes, that would work. Thanks.
-tim
Hi Tim
Yes, the design does require the DAO provider know how to interpret
the presented AclObjectIdentity.
As you know, JdbcDaoImpl (and any BasicAclDao for that matter) needs
to be able to create BasicAclEntry[]s in response to the DAO request.
Each
Thought about posting this in the forum, but thought the dev mailing
list would be a better place to bring this up.
I've gotten my prototype to successfully perform ACL authentication at
the method invocation level. So right now I'm going a bit further
beyond the standard ACL implementation
Hello !
I am new to this framework,
I have changed the default queries in
net.sf.acegisecurity.providers.dao.jdbc.jdbcDaoImpl, and now I want to
compile the project again.
I guess it should be a simple task to use ant build but It seems that
with the distribution file
[EMAIL PROTECTED] wrote:
Hello !
I am new to this framework,
I have changed the default queries in
net.sf.acegisecurity.providers.dao.jdbc.jdbcDaoImpl, and now I want to
compile the project again.
I guess it should be a simple task to use ant build but It seems that
with the distribution file
11 matches
Mail list logo
