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:34:19 GMT
Randy/Dennis,

I just responded before on the initial question from Randy when I saw this one :)

Some additional comments inline below.

Randy Watler wrote:
> Dennis/Ate,
> 
> The credential is not transient. It is persistent and I verified it was 
> written to the database. The "feature" is that setting a password is 
> deferred by transient tracking members in PasswordCredentialImpl. With 
> OBJ, a new credential instance is read from the DB on every access and 
> that circumvents the set password tracking. With JPA, the objects are 
> cached. Within the same transaction, you are ensured of getting the same 
> instance back, even if it has been flushed to the database on a commit. 
Even *after* an instance its state has been committed?
I would think that would end the transactional state/cache too, thus a subsequent read would
reload the previously committed state?

> Because its the same instance, the getPassword() access retrieves the 
> old value, despite the fact that the credential has in fact been updated.
As I mentioned in my previous response, would it be possible to use (force) multiple transactions
for this (and possibly other) test cases, 
which would be more realistic from a (user) interaction POV too?

> 
> I do not want to do something that is wrong here. The deferred password 
> set operation is there for a reason no doubt, but I am wondering if it 
> is safe to override that capability in this case. Perhaps Ate can 
> comment on why PasswordCredential does this in general and if it is 
> appropriate to disable it here?
As I already explain in previous response, it think it would *not* be appropriate to do so.
PasswordCredential handling is somewhat special because a PolicyManager and/or PasswordCredentialInterceptors
could be configured which 
might need to have their say in the validation (and storage) of an new/updated PasswordCredential.
By "clearing" the passwordSet state directly from the (higher level) API, this would be break
the "contract" of their usage.

> 
> Randy
> 
> Dennis Dam wrote:
>> Hi Randi,
>>
>> it's fine by me if you don't have other options. I guess you can't (or 
>> don't want to) force a write-through of the password, and discard the 
>> transient credential?
>>
>> regards,
>> Dennis
>>
>> -----Oorspronkelijk bericht-----
>> Van: Randy Watler [mailto:watler@wispertel.net]
>> Verzonden: ma 9-2-2009 10:41
>> Aan: Jetspeed Developers List
>> Onderwerp: SSO PasswordCredential Question
>>  
>> 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?
>>
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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