Stephane Grialet wrote:
> Hello,
>
>
>
> About the two machines we have for testing our portal application, here
> is more info:
>
>
>
> - on the development platform, we don't see anymore the
> "jsessionid=<xxxxx>" at the end of all the urls.
>
> We remember it was there at the beginning of our developements, so at
> one time we must have changed something in the configuration that
> blurred this session id... but what ?... here is the question !
>
You should see it in the URLs generated on the first request only if
cookies are enabled, and always if not.
> On this platform, our session tracking works well.
>
> I have put a "rundata.getUser().setPerm(...)" for the user variables we
> wanted to store for all the session, needed by different pages of the
> application.
>
> And on every Java program that needs the info (portlet, screen...), i
> simply make a:
>
> var = rundata.getUser().getPerm(myVar);
>
> to retrieve the variable.
>
> We don't have any DynamicUri generated (i mean all the HREF or FORM
> action links we have are "rough", e.g.
>
> <A HREF="/jetspeed/portal/screen/myScreen" TARGET="_blank">My screen</A>
>
> (with, if needed, parameters after the url: ?<myParam>=<myParamValue>&...)
>
> <FORM ACTION="/jetspeed/portal/screen/myScreen" METHOD=post>
>
> And this works fine.
This will *NOT* work if cookies are not enabled in the client browser.
Session should work with cookies enabled always, unless you are changing
server name (or adding a port) in the middle. Note that WRT cookies,
"localhost" is *not* the same as "localhost:80" For this reason I had to
patch URILookup a couple of months ago. Maybe there is still broken code
showing this problem.
>
> The Jetspeed version on this platform: 3.2.1
You mean 1.3a1 (I think). Either, you could mean *tomcat* 3.2.1
>
>
>
> - on the production platform, we see "jsessionid=<xxxxx>" on all the
> portlets links just after the connection screen (JLoginUser), but then,
> when we try to launch screens via the portlets, we lose the "jsessionid"
> and the rundata.getUser().getPerm(myVar) statement doesn't work anymore
> (gets null) !
This means that your production test browser does not have cookies
enabled, and the way you generate URLs does not call
response.encodeURL() or alternatively uses turbine's DynamicURI.
>
> Jetspeed version: 3.1.1
>
> The version is not the same, but the conf files (jetspeed-config,
> JetspeedResources...) are the same since they are coming from the same
> jetspeed.war file (from the dev platform).
>
>
>
> can someone help us knowing :
>
> - why we don't see anymore any "jsessionid=<xxxxx>" after the urls on
> the dev platform, while we saw them at the beginning of our
> developements ? and can we reproduce it on our production platform ?
>
Someone activated cookies in the browser, and you redirect and don't see
the first request. Look at the server access logs for exacts URLs
touched by the browser.
> - if this remains a mystery, can you write us the Java code for
> generating DynamicURI (for HREF and FORM action links) ? What is the
> meaning of the following interface:
>
> new DynamicURI(rundata rd, string screen, boolean b)
>
> i mean, what is the meaning of the parameters and what does this
> statement produce exactly ?
>
> The main user variables we stored in the session were the user id and
> password. We pass them to different screens from a few portlets, is the
> DynamicURI method really secured and does it fit for this use ?
>
> I mean that of course we don't want to see these variables passed at the
> end of an HREF URL.
>
If you store them at the session, they will *never* go to the client.
>
>
> thanks for any help, we do have now huge problems with our portal
> application, and if we don't succeed solving them quickly, this might
> lead to give up the Jetspeed solution and try another one.
>
>
With regards to the questions about DynamicURI, please read the class
code and javadocs. The scope of your questions is beginning to make me
think seriously about a paid consultancy proposal on servlet session
management :-)
See my mail in the previous thread about my customer's findings on
sessions without cookies.
>
> St�phane
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
