Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <49903AFE.6080508@wispertel.net>
Date: Mon, 09 Feb 2009 07:17:34 -0700
From: Randy Watler <watler@wispertel.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
Subject: Re: SSO PasswordCredential Question
References: <498FFA59.1020500@wispertel.net>
 <F8E386B54CE3E6408F3A32ABB9A7908A0198D9BF@hai02.hippointern.lan>
In-Reply-To: <F8E386B54CE3E6408F3A32ABB9A7908A0198D9BF@hai02.hippointern.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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. 
Because its the same instance, the getPassword() access retrieves the 
old value, despite the fact that the credential has in fact been updated.

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?

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