Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: None
    • Component/s: Resources
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_small importance_small

      Show
      size_small importance_small

      Description

      Currently the resources directory is hardcoded to /resources. This means that all artifacts are world-readable by default, which is a problem when you start creating component libraries. It'd be nice if either the directory was configurable (so it could be inside of WEB-INF), or if perhaps it was in WEB-INF by default.

        Issue Links

          Activity

          Hide
          arjan tijms added a comment -

          p.s. if the only reason for configuring another directory than /resources is to prevent it not being world readable, then of course there's already a workaround: define a role for it in web.xml which no user has, e.g.:

          <security-constraint>
              <web-resource-collection>
                  <web-resource-name>resources</web-resource-name>
                  <description>The resources directory</description>
                  <url-pattern>/resources/*</url-pattern>
              </web-resource-collection>
              <auth-constraint>
                  <description>No user should be able to see this.</description>
                  <role-name>arolenobodyhas</role-name>
              </auth-constraint>
          </security-constraint>
          

          The context-param would be surely simpler, but not solve the fundamental issue that those directories are unprotected by default.

          Show
          arjan tijms added a comment - p.s. if the only reason for configuring another directory than /resources is to prevent it not being world readable, then of course there's already a workaround: define a role for it in web.xml which no user has, e.g.: <security-constraint> <web-resource-collection> <web-resource-name> resources </web-resource-name> <description> The resources directory </description> <url-pattern> /resources/* </url-pattern> </web-resource-collection> <auth-constraint> <description> No user should be able to see this. </description> <role-name> arolenobodyhas </role-name> </auth-constraint> </security-constraint> The context-param would be surely simpler, but not solve the fundamental issue that those directories are unprotected by default.
          Hide
          Ed Burns added a comment -

          I have some bad news about this. Look at this javadoc from ServletContext.getResource()

          The path must begin with a / and is interpreted as relative to the current context root, or relative to the /META-INF/resources directory of a JAR file inside the web application's /WEB-INF/lib directory. This method will first search the document root of the web application for the requested resource, before searching any of the JAR files inside /WEB-INF/lib. The order in which the JAR files inside /WEB-INF/lib are searched is undefined.

          If we're going to allow this sort of thing at all, I think it would be confusing for it to just be available in JSF. In other words, this is a broader problem than just JSF. On the other hand, the Servlet spec doesn't have a concept of a "resources" directory within the web application root, so the javax.faces.WebAppResourcesDirectory portion of this feature request is still relevant to handle in JSF.

          AT> Is there any chance that the defaults could be set to save paths
          AT> (non-world readable) and that people could use those context-params
          AT> to restore the old behavior if they need that?

          AT> I do realize that this would initially hurt backwards compatibility
          AT> as everyone would either have to move their resources or learn about
          AT> this setting, so it's probably not an easy decision.

          I'm sorry, but I can't support that kind of change.

          Result: Let's just stick with the javax.faces.WebAppResourcesDirectory
          context-param.

          Show
          Ed Burns added a comment - I have some bad news about this. Look at this javadoc from ServletContext.getResource() The path must begin with a / and is interpreted as relative to the current context root, or relative to the /META-INF/resources directory of a JAR file inside the web application's /WEB-INF/lib directory. This method will first search the document root of the web application for the requested resource, before searching any of the JAR files inside /WEB-INF/lib. The order in which the JAR files inside /WEB-INF/lib are searched is undefined. If we're going to allow this sort of thing at all, I think it would be confusing for it to just be available in JSF. In other words, this is a broader problem than just JSF. On the other hand, the Servlet spec doesn't have a concept of a "resources" directory within the web application root, so the javax.faces.WebAppResourcesDirectory portion of this feature request is still relevant to handle in JSF. AT> Is there any chance that the defaults could be set to save paths AT> (non-world readable) and that people could use those context-params AT> to restore the old behavior if they need that? AT> I do realize that this would initially hurt backwards compatibility AT> as everyone would either have to move their resources or learn about AT> this setting, so it's probably not an easy decision. I'm sorry, but I can't support that kind of change. Result: Let's just stick with the javax.faces.WebAppResourcesDirectory context-param.
          Hide
          Ed Burns added a comment -

          Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
          Transmitting file data .
          Committed revision 9772.

          Sending preface.fm
          Sending usingFacesInWebapps.fm
          Transmitting file data ..
          Committed revision 1053.

          Show
          Ed Burns added a comment - Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java Transmitting file data . Committed revision 9772. Sending preface.fm Sending usingFacesInWebapps.fm Transmitting file data .. Committed revision 1053.
          Hide
          arjan tijms added a comment -

          I've got a question about the initial slash of the resources directory setting. The JavaDoc says the following now:

          If a <context-param> with the param name equal to the value of WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME exists, the runtime must interpret its value as a path, relative to the web app root, where resources are to be located. This param value must not start with a "/", though it may contain "/" characters. If no such <context-param> exists, or its value is invalid, the value "resources", without the quotes, must be used by the runtime as the value.

          So it says not to start with a "/".

          However, Mojarra's default in `WebConfiguation` does start with a "/":

          WebAppResourcesDirectory(
              ResourceHandler.WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME,
              "/resources"
           )
          

          The comment given by Ed Burns - 27/Feb/12 09:38 PM also says that the path should not start with a "/":

          If this param is set, it must start with a "/" and the runtime will interpret its value to be the path of the resources directory for resources packaged in the Web Application Root as specified in section 2.6. If not specified, the default value is "/resources"

          Is there any mismatch here, or am I misinterpreting either the code or the JavaDoc?

          Show
          arjan tijms added a comment - I've got a question about the initial slash of the resources directory setting. The JavaDoc says the following now: If a <context-param> with the param name equal to the value of WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME exists, the runtime must interpret its value as a path, relative to the web app root, where resources are to be located. This param value must not start with a "/", though it may contain "/" characters. If no such <context-param> exists, or its value is invalid, the value "resources", without the quotes, must be used by the runtime as the value. So it says not to start with a "/". However, Mojarra's default in `WebConfiguation` does start with a "/": WebAppResourcesDirectory( ResourceHandler.WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME, "/resources" ) The comment given by Ed Burns - 27/Feb/12 09:38 PM also says that the path should not start with a "/": If this param is set, it must start with a "/" and the runtime will interpret its value to be the path of the resources directory for resources packaged in the Web Application Root as specified in section 2.6. If not specified, the default value is "/resources" Is there any mismatch here, or am I misinterpreting either the code or the JavaDoc?
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              kito75
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h