Portals Bridges
  1. Portals Bridges
  2. PB-93

Allow configuring a custom error page for HTTP 403 (access denied)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: struts
    • Labels:
      None
    • Environment:
      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

      1. error403.war
        2.45 MB
        Fernando Silva Lozano
      2. pb-struts-error403.patch
        3 kB
        Fernando Silva Lozano

        Activity

        Hide
        Fernando Silva Lozano added a comment -

        Adds init parameter HttpError403Page to StrutsPortlet so renderError includes an user-friendly error page when an action mapping is configured with a roles attribute.

        Show
        Fernando Silva Lozano added a comment - Adds init parameter HttpError403Page to StrutsPortlet so renderError includes an user-friendly error page when an action mapping is configured with a roles attribute.
        Hide
        Fernando Silva Lozano added a comment -

        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.

        Show
        Fernando Silva Lozano added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Fernando Silva Lozano
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development