portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@jakarta.apache.org>
Subject [jira] Resolved: (JS2-184) Action urls are being corrupted if your session expires and you get redirected
Date Wed, 12 Jan 2005 13:51:17 GMT
     [ 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:
If you want more information on JIRA, or have a bug to report see:

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

View raw message