Jared Odulio wrote:
Hi Mark,
Thanks, I've registered already. So while waiting for the activation
email to arrive. I am going to post a few more info. I am using Acegi
Security version 0.9.0 Snapshot that I build myself. I am running the
Contact Sample and my application in Sun Java System
Hi Ben,
Yes, I managed to fix it. I have taken some notes too:
http://jaredtech.blogspot.com/2005/08/webworkvelocityacegi-config.html
I am if this is case works for others but it worked for me.
Ben Alex wrote:
Jared Odulio wrote:
Hi Mark,
Thanks, I've registered already. So while waiting
Robert r. Sanders wrote:
After a couple false starts which in retrospect I shouldn't have
checked into the CVS HEAD, I have finally cleaned up the code and
gotten an updated version of the LDAPPasswordAuthenticationDao, along
with a unit test, into the CVS HEAD. I will post a similar message
Mark St.Godard wrote:
The HttpSessionContextIntegrationFilter should be able to set some
sort of indicator that this is the first logon attempt since it
generates a new SecurityContext however this wouldnt work for
remote client authentication?
IMHO we should modify all event-aware
Mark St.Godard wrote:
I did some local testing with the Contacts sample and did some simple tests of
- logging in (i.e. User 1)
- going to /secure/debug.jsp (view User 1 info)
- going to a jsp that handles the switch (i.e. switchUser.jsp)
- submit request to 'su' to another user (i.e. User 2)
Andy Depue wrote:
I wonder, though, if the ACL functionality would be a
better solution for this sort of thing? The Voter we created below was just
a quick hack, really.
The BasicAclVoter is designed to locate the first domain object argument
in a method invocation, and then lookup the
Tim Kettering wrote:
I’m wondering if there was a reason that most of Acegi’s standard ACL
classes use int when dealing with object id values. We usually default
to using ‘long’ instead of ‘int’ – and I believe that other places do
as well, so it seems to me that it might be simpler to use
Jared Odulio wrote:
Hi Ben,
Yes, I managed to fix it. I have taken some notes too:
http://jaredtech.blogspot.com/2005/08/webworkvelocityacegi-config.html
I am if this is case works for others but it worked for me.
Hi Jared
I added your blog entry to our articles page to help others find
Clarence Ho wrote:
java.lang.ClassCastException:
net.sf.acegisecurity.providers.UsernamePasswordAuthenticationToken
Most ClassCastExceptions are caused because there's an extra
acegi-security-*.jar on your classpath. It should only be inside your
WAR's WEB-INF/lib directory.
Cheers
Ben
Hi Ben, (welcome back :)
Great, the isAuthenticated() is the exact key we need to determine
this particular even, irrespective of the cache.
I also agree that it should not be in the AuthenticationProviders...
Ben, I created a JIRA entry for this (SEC-50), you can assign to me
if you want.
Hey Ben,
Just wanted to mention, I have started converting over the
attributes sample apps over to Java 5 annotations version. (Havent
checked in yet)
samples/attributes (Commons)
samples/annotations (Java 5)
Basically, I ported over the BankService code and created tests.
Also, I did port
Mark St.Godard wrote:
I just wanted to make sure I dont check in code that breaks JDK 1.4
users from building the CVS HEAD examples, etc.
Therefore to sum up:
- can we package the core-tiger classes into the single acegi security dist?
- where should the new samples (for java5) be located?
12 matches
Mail list logo
