Details
-
New Feature
-
Status: Open
-
Blocker
-
Resolution: Unresolved
-
None
-
None
-
None
-
eXo PC 2.0.5 or eXo WCM 1.0, JBoss AS 4.2.3
Description
When using Java EE declarative security with struts we rely on web.xml <security-constraint> and <error-page> to block access to unauthorized pages and display a friendly error page so, if for example the user followed a bookmark to a page he doesn't have access anymore, he can return to normal application navigational flow.
Both elements become no-ops inside a portlet container, but Struts own action mapping has a roles attribute that replaces the <security -constraint>. But it has no replacement for <error-page>. Struts returns the access denied error as an HTTP 403 error and not an exception, so Struts exception handlers cannot be used to provide the user friendly error page.
As a portlet cannot return HTTP errors to the user browser, the StrutsPortlet from Struts Portlet Bridge has a method renderError that displays in a hard-coded error page information about the error. I patched this method so, if found an the parameter "HttpError403Page", the Struts Portlet includes the page given as the paramter value. If not, or if there's an exception while including, continue to the hard-coded error page.
The portlet init parameter is non-intrusive and follows the portlet bridge convention of using those to configure default pages for edit, help and view portlet modes.
Although my tests were made on eXo Platform, I think the issue and my fix are generic enough to affect and work with any portlet container.
You can see my message on the apache portals mailing list (the first one from november 2009) for a more detailed explanation.
http://mail-archives.apache.org/mod_mbox/portals-bridges-user/200911.mbox/browser