I am running Mac OSX. The file system write issue does not make sense
to me if I can see the change has occurred using Apache Dir Studio
before the reboot. I *could* try the upgrade to 1.5.3, but *should* I?
How stable is that version compared to 1.5.3?
Just a thought... if the webapp (Spring Security) pools the connection
and keeps it alive with the old password, could that explain the
scenario? I am not positive that a new bind request is actually flowing
to Apache DS - can I see all bind attempts in the log file? Has anyone
else seen this with Spring Security or pooling of LDAP connections?
Thanks!
Rich
Emmanuel Lecharny wrote:
Rich Remington wrote:
I am curious is there is an article/example that describes how to
deal with the following scenario:
1. User logs into webapp that uses Spring Security (v2.0.3) backed by
Apache DS 1.0.2.
2. Webapp (via an ESB service) changes password in LDAP
- using Apache Dir Studio (v1.1.0), I can see the password has
changed in the directory
3. After a logout from webapp, a quick attempt to login with new
password fails, but using the old password works.
It turns out that I need to reboot Apache DS to affect the password
change in the webapp. A reboot of the webapp after step 3 has no
affect.
You have to check that the files handling the data are written on
disk. You may have pb with your file system writes. Otherwise, there
is a cache, yes, but you can tell the server to sync on write (there
is a flag in the partition configuration : <property
name="synchOnWrite" value="true" />).
It may also be a bug in ADS 1.0.2...
