portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: SSO PasswordCredential Question
Date Mon, 09 Feb 2009 23:31:26 GMT
Ate,

One purpose of an extended/conversational entity manager, (i.e. long 
transactions), is to cache versions of attached objects that have been 
accessed during its lifetime. This means that things like object level 
'==' operations can be used to imply object identity. Obviously, that is 
natural for POJO style Java coding. In the test harnesses, the default 
lifetime is established per test thread. In the portal, we have choices 
to make there, but I envision it to be roughly analogous to portal 
requests. It does not matter when commits or rollbacks are made against 
the entity manager, the attached objects span its entire lifetime. The 
Seam framework utilizes this approach to minimize the attach/detach 
operations that would be otherwise necessary as code crossed various 
transactional proxy boundaries.

So, yes, the exact same object instance is returned by JPA in this mode 
whether the object is about to be or has been committed. As you can 
imagine, this caused unexpected behavior with the transient tracking 
members in PasswordCredentialImpl. If we want the credential to clear 
its state on a commit, we should do that explicitly. In the past, we 
relied on subsequent gets returning brand new instances which had their 
"new password" state cleared. This is a difference between OJB and the 
conversational JPA approach. So would it be correct then to invoke 
PasswordCredentialImpl.clearNewPasswordSet() when the object is written 
to the database? At least then the dirty credential would be left in the 
same state after a commit that a new credential fetched from the DB 
would be in... that seems more consistent than the current 
implementation. All of the managers and interceptors you discussed below 
should have already processed the credential by the time it commits, no?

As you can tell, I am nervous about the "OJB" hangover in our code base 
and am trying to get it right from a conversational JPA POV. One other 
interesting fact about JPA caching is that no instance is EVER shared 
between entity managers. There is a cache, but it stores objects as a 
list of fields that are used to reload new objects for each 
conversational entity manager scope. At first, I was dismayed by this, 
but it is handy when you think about the transient state management 
issues that can come up otherwise. I am not sure how you intended the 
transient tracking of PasswordCredentialImpl to operate from an 
isolation perspective, but I am pretty sure it is safe to think about it 
as having the scope of one conversation/thread/request.

With regard to the test case we have been discussing, I did force it to 
utilize separate transactions/conversations to initially create the sso 
user+credential, to set a new password, and to validate the fact the 
password was changed. This makes the test run more like OBJ does and new 
conversation-specific instances of the user and credential are operated 
on and validated in each step. Of course, this makes it a more realistic 
test case as you point out, (normally these would happen in 3+ requests 
into the portal).

I hope this answers some of your questions and fills in some background. 
I might be a bit off in my explanation in the dark corners here and 
there, but you should get the idea where I am coming from in any case. 
Please consider my proposal to clean up the transient state of 
PasswordCredentialImpl on commit, (persist/update). It may not make any 
difference to you or OJB, but I'd sleep better knowing that the internal 
state of these conversational attached objects is maintained in a 
consistent manner.

Thanks,

Randy

Ate Douma wrote:
> 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
>
>


---------------------------------------------------------------------
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