Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Message-ID: <1116195531.1105537877809.JavaMail.jira@ajax.apache.org>
Date: Wed, 12 Jan 2005 14:51:17 +0100 (CET)
From: "Ate Douma (JIRA)" <jetspeed-dev@jakarta.apache.org>
To: jetspeed-dev@jakarta.apache.org
Subject: [jira] Resolved: (JS2-184) Action urls are being corrupted if your
 session expires and you get redirected
In-Reply-To: <994203785.1104864372854.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/JS2-184?page=history ]
     
Ate Douma resolved JS2-184:
---------------------------

     Resolution: Fixed
    Fix Version:     (was: 2.0-dev/cvs)
                     (was: 2.0-FINAL)

The problem turned out to be a combination of two.

First, in the ProfilerValveImpl, the profiled page was set to "/" when a SecurityException was thrown and the user wasn't logged on (anymore).
This resulted in the rendered page to be out of sync with the request url (meaning: PortalURL).
PortletURLs generated for this page thus were still referring to the original page (the TestSuite page in your example).

Secondly, the window actions are generated by the JetspeedPowerTool in getDecorationActions().
This method caches the generated actions for each window in the session and only generates them once
per session. This is done (according to the javadoc) because of performance.

As the first time after session timeout the decoration actions are generated with the *wrong* PortalURL context
(still pointing to the non-accessible page, TestSuite in your case), these wrong decoration actions will be reused
for the home page windows until the current user logs out again.
Note: session-state is preserved when a user logs on, only cleared when a user logs out!

I solved this problem by sending a client-side redirect from ProfilerValveImpl instead of profiling the home page.
Thus the PortalURL state remains in sync with the page rendered.

We *must* keep the profiled page in sync with the request url at all times to prevent this kind of problems.
If a client-side redirect is *not* possible where the profiled page isn't in sync with the requested url (server-side
redirect), the PortalURL path attribute probably should be updated. Currently, this isn't possible because the setPath()
method is protected (the PortalURL state should usually be considered immutable in my opinion).

The caching of the DecorationActions in the JetspeedPowerTool might cause more problems once we properly implement
the securityCheck for these actions. If the guest (not-logged on) user doesn't have access to certain actions, but the
logged on user does, the cached DecorationActions won't be reexamined after login, thus the user still won't get access
to the additional actions.

I don't know what the status of the security check implementation is, nor who worked or works on them. Right now, all
allowed portlet/window actions (as defined in the portlet.xml) are available to all.
The security constraints as defined in the psml and related files are not enforced yet!

> Action urls are being corrupted if your session expires and you get redirected
> ------------------------------------------------------------------------------
>
>          Key: JS2-184
>          URL: http://issues.apache.org/jira/browse/JS2-184
>      Project: Jetspeed 2
>         Type: Bug
>   Components: Aggregation
>     Versions: 2.0-dev/cvs, 2.0-a1, 2.0-M1, 2.0-M2
>     Reporter: Scott T Weaver
>     Assignee: Ate Douma
>      Fix For: 2.0-M2

>
> Here are the steps to reproduce this bug.
> 1. Login as admin.
> 2. Let the session expire.
> 3. Click the Test Suite Page tab.  You will be re-directed to the default welcome page.
> 4. Now all of the action button (min,max,etc.) urls' have the testsuite.psml tacked onto the end of them.  The actions are now effectively broken.
> Not sure why this is happening.  
> David or Ate, do you guys have any idea why this is happening? 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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