[#JS2-184] Action urls are being corrupted if your session expires and you get redirected

Jetspeed 2

Action urls are being corrupted if your session expires and you get redirected

Created: 05/Jan/05 03:36 AM Updated: 12/Jan/05 10:47 PM

Return to search

Component/s:

Aggregation

Affects Version/s:

2.0-dev/cvs, 2.0-a1, 2.0-M1, 2.0-M2

Fix Version/s:

2.0-M2

Time Tracking:

Not Specified

Resolution Date:

12/Jan/05 10:46 PM

Description

« Hide

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?

All

Comments

Work Log

Change History

Subversion Commits

Sort Order:

[ Permlink | « Hide ]

Ate Douma added a comment - 12/Jan/05 06:48 AM

Reproduced.
I'll look into this one.

[ Permlink | « Hide ]

Ate Douma added a comment - 12/Jan/05 10:46 PM

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!

[ Show » ]

Ate Douma added a comment - 12/Jan/05 10:46 PM 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!