portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <pau...@apache.org>
Subject Re: How a Profile is associated with a request
Date Fri, 10 May 2002 18:36:21 GMT


Glenn Golden wrote:

> 
>>-----Original Message-----
>>From: Paul Spencer [mailto:paulsp@apache.org] 
>>Sent: Friday, May 10, 2002 2:06 PM
>>To: Jetspeed Developers List
>>Subject: Re: How a Profile is associated with a request
>>
>>
>>
>>
>>Glenn Golden wrote:
>>
>> > DefaultJetspeedRunData's getProfile() setProfile() store 
>>the Profile  >  in the getUser().getTemp("profile").
>>
>> >
>> > Does anybody know why we choose to store the profile in 
>>the session  > rather than the run data?  >
>>
>>Rundata is recreated every request, getUser().getTemp() stays 
>>around to 
>>for the entire session.
>>
> 
> 
> Right - but we re-create the Profile for each request, so why store it long
> term like that?
> 


Should like we should compare the "path".  If they are different then 
get the profile, other use the one in getTemp()

> 
<snip>> 

>>They should be 2 different sessions.  I suspect two browses 
>>running on 
>>the same PC will share the same cookies, this the same 
>>session.  Browser 
>>on different machines will have different sessions.
>>
> 
> 
> What I's saying is that two different browser windows on the same machine
> will be in the same HTTP session, and we have to allow this to happen, and
> different portal pages to be in each browser without conflict.  Better yet,
> we have to allow the *same* portal page in both browsers without conflict.

 >

Session management is a function of Tomcat, not jetspeed.  If the user 
desire 2 session on the same machine, then the user has to disable 
cookies or make sure their browser do not share cookies.  I do not 
believe this is a Jetspeed problem.

> 

> Storing Page session state information in the HTTP session introduces
> conflict between different pages in different windows.
> 
> Storing the profile in the HTTP session introduces conflict of the same
> sort.
> 
> And as far as I can tell, we are doing it for no benefit.
> 


Tomcat is managing the session from the browser, not Jetspeed.

> 
<snip>

> 
> 
> Each request computes the profile from the URL in JetspeedAccessController.
> 
> Even if it didn't, if I request a user/group/role page, and then my next
> request is for just /portal/, the second request is for my default page, not
> the one I got the first time.  This is why the $jslink is so important to
> encode all the profile page stuff so that links back will identify the
> proper page.
> 


I stand corrected.


> 
>>
>>Paul Spencer
>>
>>
Paul Spencer



--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message