You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by "Fernando Silva Lozano (JIRA)" <br...@portals.apache.org> on 2009/11/09 15:52:34 UTC
[jira] Created: (PB-93) Allow configuring a custom error page for
HTTP 403 (access denied)
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
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-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Updated: (PB-93) Allow configuring a custom error page for
HTTP 403 (access denied)
Posted by "Fernando Silva Lozano (JIRA)" <br...@portals.apache.org>.
[ 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-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Updated: (PB-93) Allow configuring a custom error page for
HTTP 403 (access denied)
Posted by "Fernando Silva Lozano (JIRA)" <br...@portals.apache.org>.
[ 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org