portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: SSO PasswordCredential Question
Date Mon, 09 Feb 2009 14:24:51 GMT
Randy Watler wrote:
> Ate/Dennis,
> 
> In SSOManagerImpl.setPassword(), we invoke 
> PasswordCredential.setPassword(xxx, false) from 
> TestSSOManager.testCredentials() and then requery the password later in 
> the test to see if it has changed.
> 
> This works fine with OBJ, but with JPA I get the same PasswordCredential 
> instance back on the requery because it is in an 
> 'Extended'/'Conversational' transaction. As a result, the 'new password 
> set' transient tracking in PrincipalCredentialImpl is active and is as 
> if the user just set the password. This means that the 
> PasswordCredential.getPassword() returns the previous password value and 
> the test fails.
> 
> I am wondering if immediately after the PasswordCredential.setPassword() 
> call the SSOManagetImpl.setPassword() method should invoke 
> PasswordCredential.clearNewPasswordSet()? That seems like it might make 
> sense in this case since we're forcing a password change, no?
For this test that might work, but it can "break" the (generic, e.g. not SSO related) logic
in for instance the 
UserPasswordCredentialPolicyManager and/or specific PasswordCredentialInterceptors.
By calling clearNewPasswordSet, the internal state (isNewPasswordSet()) is cleared as well,
which might (and is!) used to determine if 
something changed on the PasswordCredential.

Now, for SSO this might be less important, at least how it *currently* is used/implemented,
but that doesn't mean someone else might want to 
build upon this and expect to be able to rely on the PasswordCredential API like isNewPasswordSet()
for proper operation.

As I understand this issue really comes from our Extended/Conversational JPA transaction management.
That is definitely an important feature performance wise so I'm not questioning it.
But to "simulate" the proper (user) interaction with this test-case (and possibly others too),
shouldn't we then "play" multiple (JPA) 
requests/transactions then as well? That would solve this issue too AFAIK, without need for
"manipulating" the API.

Ate

> 
> Randy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message