Details
Description
After fixing MYFACES-3530 I enabled Java2 Security in Websphere Application Server Version 8.0 and found the following issue related to using a custom Exception Handler to handle a ViewExpiredException.
When we Navigate to a page from the customer Exception Handler in the application the following exception occurs:
java.security.AccessControlException: Access denied org.osgi.framework.AdminPermission (id=65) resolve,resource)
at java.security.AccessController.checkPermission(AccessController.java:108)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:544)
at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208)
at org.eclipse.osgi.framework.internal.core.BundleResourceHandler.checkAuthorization(BundleResourceHandler.java:289)
at org.eclipse.osgi.framework.internal.core.BundleResourceHandler.parseURL(BundleResourceHandler.java:128)
at java.net.URL.<init>(URL.java:608)
at java.net.URL.<init>(URL.java:476)
at java.net.URL.<init>(URL.java:425)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.myfaces.view.facelets.compiler.SAXCompiler.doCompileViewMetadata(SAXCompiler.java:712)
at org.apache.myfaces.view.facelets.compiler.Compiler.compileViewMetadata(Compiler.java:126)
at org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory._createViewMetadataFacelet(DefaultFaceletFactory.java:311)
at org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.getViewMetadataFacelet(DefaultFaceletFactory.java:394)
at org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.getViewMetadataFacelet(DefaultFaceletFactory.java:376)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._getViewMetadataFacelet(FaceletViewDeclarationLanguage.java:1940)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.access$000(FaceletViewDeclarationLanguage.java:129)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage$FaceletViewMetadata.createMetadataView(FaceletViewDeclarationLanguage.java:2049)
at org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:174)
at com.ibm.ws.jsf.fat.test.PM62254.ViewExpiredExceptionExceptionHandler.handle(ViewExpiredExceptionExceptionHandler.java:45) -> Application code
I've attached Exception.txt showing the full stack trace for reference. The exception looks to come from:
org.apache.myfaces.view.facelets.compiler.SAXCompiler.doCompileViewMetadata(SAXCompiler.java:712).
I've attached a suggested patch that wraps the offending code in an AccessController.doPrivileged block. I had to make the following changes to completely fix the problem:
1) Make the ViewMetadataHandler and SAXParser local variables final so they can be used within the doPrivileged block.
2) I had to create a secondary InputStream object "finalInputStream which is just a copy of the local "is" InputStream but is marked final so it can also be used within the doPrivileged block.
3) I also added a nested try/catch block that will catch the PrivilegedActionException and catches the SAXException/IOException and keeps the behavior we had before ( throwing IOException, throwing new FaceletException for the SAXException ). I had to do this since the doPrivileged block wraps the exceptions from parser.parse in a PrivilegedActionException.
4) The new code is only used if System.getSecurityManager() != null so there should be no performance ramifications if security is not enabled.
Please review and let me know if you are ok with my patch.
Thanks!