5 Replies Latest reply on Jul 3, 2013 9:28 AM by cfillot Branched to a new discussion.

    getCodeSigners() returning null for WAR deployments

    cfillot

      Hi all,

       

      I sign (with jarsigner) .war and ejb .jar files insider an EAR. When I use clazz.getClass().getProtectionDomain().getCodeSource().getCodeSigners() in an EJB, no problem

      I get the appropriate info. However, for classes in the WAR deployment, I get a null pointer.

       

      After some analysis (I hope I'm correct here), I found that the ProtectionDomain is created within jboss-modules (in ModuleClassLoader), with CodeSigners being filled in a ClassSpec

      by a ResourceLoader. In JBossAS/WildFly, this is VFSResourceLoader that does the job. If the classes are backed by a JAR file (JavaZipFileSystem), this causes no problem (the

      CodeSigners are read from the JAR entries).

       

      However, if this is is backed by a real file system (RealFileSystem), getCodeSigners systematically returns null.

       

      Depending on how the deployment has been set up by EarStructureProcessor (exploded or not), the JavaZipFileSystem or RealFileSystem is used. For a WAR, the deployment

      is systematically exploded.

       

                  // if there is no application.xml then look in the ear root for modules
                  if (!appXmlPresent) {
                      for (final VirtualFile child : childArchives) {
                          final boolean isWarFile = child.getName().toLowerCase(Locale.ENGLISH).endsWith(WAR_EXTENSION);
                          final boolean isRarFile = child.getName().toLowerCase(Locale.ENGLISH).endsWith(RAR_EXTENSION);
                          this.createResourceRoot(deploymentUnit, child, isWarFile || isRarFile, isWarFile);
                      }
                  } else {

                      /* ... */

                  }

       

      I replaced the 4th parameter of createResourceRoot() by false, and now the CodeSigners are correctly read. However, I suppose that if a deployment is marked to be exploded, this is for

      a good reason. Any thoughts about this ? Will it cause problems in situations I haven't figured ?

       

      Thanks in advance,

       

      Christophe