Hi there,
I started this on the Apache Portals Bridges mailing list but had no replies so far. I have already submitted a patch and an opened a ticket on Apache JIRA (PB-93) and hope someone here can provide feedback on my approach to the problem, maybe even expedite it's inclusion on a new release from Apache Portals. It's related to Struts 1.x (is it still in active development, or at least supported?) but maybe the issues are present also in Struts 2 -- I had a similar issue with JSF and found the problem was not considered either by the MyFaces developers, MyFaces Portlet Bridge developers, or the JSR-301 and JSR-286 expert groups. I'd also appreciate If someone can comment on the same issues regarding declarative security and Struts 2. Here's the original, yet unanswered message from the apache portals bridges mailing list: ---------------------- I some issues with Java EE declarative security and Struts 1.x Portlets, and a patch that solves some of them. I just wish feedback from users and developers on those issues and my ideas about them before opening a JIRA ticket abd submiting my patch. Althouth some developers perfer to ignore Java EE security completely, and use either Acegi or some in-house (in-)security solution, if you do use Struts or JSF you can leverage standard declarative security with ease. But, when you move from from servlets to portlets, you give up all declarative security features, that is, web.xml <security-constraints> become noops. It's not so bad with Struts, where you can still use roles in action mappings, but with JSF and plain servlet development you nave no option but hand coded programatic security. :-( I understand portlets don't have URI so at first you would not have away to implement declarative security for portlets. Actually, most frameworks use a navigation parameter (navigational state) to emulate request URLs -- This is the case with both the standard JSF portelt bridge and the Apache Portals struts portlet bridige from apache portals. So it would be feasible for a portlet bridge to read <security-constraints> from web.xml and emulate their working as if in a servlet container. In the general case, there could be a <security-contraint> inside portlet.xml with subelements as <parameter-name> and <parameter-value> to replace <uri-pattern> from web.xml, and the portlet container could enforce declarative security access control using the navigational context. I don't believe I was the first to think about this but I think this is a big omission from all JSRs related to portlet development under Java EE. :-( Another, but related, issue: back to JSF (and also struts) in a servlet container we would use a web.xml <error-page> element for <error-code> 403 to display a user-friendly "access denied" page. We also loose this capability inside a portlet container, but that's another thing a portlet bridge could emulate with ease. And that's another thing we could have properly implemented in portlet.xml, maybe as an exception handler so portlets don't get configured for http error codes. So there are actually two issues: 1. Enforcing declarative security access controls inside a portlet container -- Struts already solves that using <action-mapping> roles attribute, which is compatible with both servlet and portlet containers; 2. Dsiplaying an user-friendly error page, which in a servelt container is done by the container itself but not by a portlet container, and neither Struts nor the Apache Portals Portlet Bridge provide an alternative. My first idea at (2) was to simply subclass the StrutsPortlet and override the renderError() method. But this is quite restrictive as the original method can't use a RequestDispatcher to include a JSP error page or call an Struts action. Throwing an exception is also not an option, because exception thrown by StrutsPortlet don't reach the error handler configured by struts-action.xml My solution is to patch StrutsPortlet so it pass the proxied ServletContext and HttpServeltRequest to renderError, and use either a portlet init-param or context-param to configure an error page by http error code, replacing thus the web.xml <error-page> element, and leaving generic exceptions to the struts error handler. It's a trivial patch and solves my issues until the portlet API provides a better solution, or someone (maybe me) thinks about emulating web.xml declarative security features inside the portlet bridge. []s, Fernando Lozano 4Linux Software, Brazil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
