[
https://issues.apache.org/jira/browse/PB-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fernando Silva Lozano updated PB-93:
------------------------------------
Attachment: pb-struts-error403.patch
Adds init parameter HttpError403Page to StrutsPortlet so renderError includes
an user-friendly error page when an action mapping is configured with a roles
attribute.
> Allow configuring a custom error page for HTTP 403 (access denied)
> ------------------------------------------------------------------
>
> Key: PB-93
> URL: https://issues.apache.org/jira/browse/PB-93
> Project: Portals Bridges
> Issue Type: New Feature
> Components: struts
> Environment: eXo PC 2.0.5 or eXo WCM 1.0, JBoss AS 4.2.3
> Reporter: Fernando Silva Lozano
> Priority: Blocker
> Attachments: pb-struts-error403.patch
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
