[ 
https://issues.apache.org/jira/browse/PB-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fernando Silva Lozano updated PB-93:
------------------------------------

    Attachment: error403.war

A simple CRUD portlet that needs an user with either roles 'gerente' or 
'equipe' to change data. This allows seeing the problem (if portlet 
init-parameter 'HttpError403Page' is commented out) or see the patch attached 
to this issue working.

Sorry, test application in portuguese, but it's so simple (no db, java Map used 
as 'in-memory' db) I hope no one will have problem following it. If need I can 
translate to english.

Configuration files and dependent jars in WEB-INF/lib reflects my development 
environment using eXo Platform but there should be nothing in the code which is 
not JSR-168 / JSR-286 compliant and would prevent working with another portlet 
container.

> 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: error403.war, 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: bridges-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: bridges-dev-h...@portals.apache.org

Reply via email to