LDAP authentication, internal password reset

[Adam Harding]

I've had some LDAP-authenticating user accounts become unable to log in after the users edited their *internal* accounts' passwords (using the "(Edit)" link -> Change Password in the form). The LDAP authenticator only attempts to use LDAP if StringUtils.isEmpty(XDATUser.getPrimaryPassword()) is true for the account attempting to log in, otherwise it tries using local login. I've tried empty-ifying the password (hash) simply by saying:

UPDATE xdat_user SET primary_password='' WHERE login='theUserName';

but this doesn't allow the account to log in; the behavior is the same. When I trace .getPrimaryPassword() for the account, I see that the old password (hash) has persisted rather than being emptied, despite its no longer being in the database at xdat_user.primary_password for the account (verified again with psql). This persists across restarts of the DBMS service and XNAT.

XDATUser.getPrimaryPassword() comes from the interface XdatUserI, implemented by XDATUser's ancestor AutoXdatUser, which is where it seems to use ItemWrapper.getStringProperty(String) from xft, etc...

So something is preventing this approach. What am I missing?
[Is the XNAT talking to the backing db I think it is? Thought of that: yes it is, but that's not to say the problem/fix couldn't be similarly naive.]

[Timothy Olsen]

The user object uses some outdated db-side caching.  That is probably your problem.  Run this DELETE FROM xs_item_cache;  Or something like that.

This should be moved to ehcache or some proper caching structure. 

Tim

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/xnat_discussion/-/x_Xe-CTwUEcJ.
To post to this group, send email to xnat_di...@googlegroups.com.
To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xnat_discussion?hl=en.

[Adam Harding]

Clearing xs_item_cache does the trick, thanks!

On Tuesday, June 19, 2012 1:06:06 PM UTC-5, Tim Olsen wrote:

The user object uses some outdated db-side caching.  That is probably your problem.  Run this DELETE FROM xs_item_cache;  Or something like that.

This should be moved to ehcache or some proper caching structure. 

Tim

On Tue, Jun 19, 2012 at 12:38 PM, Adam Harding wrote:

I've had some LDAP-authenticating user accounts become unable to log in after the users edited their *internal* accounts' passwords (using the "(Edit)" link -> Change Password in the form). The LDAP authenticator only attempts to use LDAP if StringUtils.isEmpty(XDATUser.getPrimaryPassword()) is true for the account attempting to log in, otherwise it tries using local login. I've tried empty-ifying the password (hash) simply by saying:

UPDATE xdat_user SET primary_password='' WHERE login='theUserName';

but this doesn't allow the account to log in; the behavior is the same. When I trace .getPrimaryPassword() for the account, I see that the old password (hash) has persisted rather than being emptied, despite its no longer being in the database at xdat_user.primary_password for the account (verified again with psql). This persists across restarts of the DBMS service and XNAT.

XDATUser.getPrimaryPassword() comes from the interface XdatUserI, implemented by XDATUser's ancestor AutoXdatUser, which is where it seems to use ItemWrapper.getStringProperty(String) from xft, etc...

So something is preventing this approach. What am I missing?
[Is the XNAT talking to the backing db I think it is? Thought of that: yes it is, but that's not to say the problem/fix couldn't be similarly naive.]

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/xnat_discussion/-/x_Xe-CTwUEcJ.

To post to this group, send email to xnat_discussion@googlegroups.com.
To unsubscribe from this group, send email to xnat_discussion+unsubscribe@googlegroups.com.