4

Is it valid, standard and best practice to place

  • publicly accessible pages be outside the WEB-INF folder such as

    index.jsp, home.jsp, store.jsp, login.jsp, registration.jsp... and

  • secured pages like

    admin.jsp, reports.jsp, manageusers.jsp, manageproducts.jsp...

    be inside the WEB-INF folder for the security reasons(cannot directly access via url) by creating controller servlets to access them

  • and for includes like

    navigation.jsp, header.jsp, footer.jsp, sitemap.jsp...

    be in specially protected directory for not to be directly access from url ??

2 Answers2

2

This sounds a little like someone is having a debate, and wants a tie breaker? :)

This could be sliced a thousand ways... but I personally wouldn't describe the purpose of placing them in WEB-INF for security reasons, it is purely because you do not want the user directly accessing those resources, for a variety of reasons.

It is possible that you could utilize WEB-INF as part of your security infrastructure, but I wouldn't say that is a standard best practice. Security should start at the request level, and however you deliver those resources to the user is up to you - WEB-INF isn't "the" solution, and it doesn't "need" to be.

Placing accessible resources outside of WEB-INF... well, sure, why not?

Different frameworks might have you place all resources inside WEB-INF somehow, and make them accessible through various controller/filter/serlvet mechanisms, but that would solely be a property of the framework, and shouldn't lead you to believe that placing resources outside of WEB-INF is a no-no.

slambeth
  • 887
  • 5
  • 17
0
  1. When you place the JSP pages "outside" of WEB-INF, the Default-Servlet of your Servlet Container (such as Tomcat) will inspect the URL, invoke the JSPs and send back Response to the Browser.

  2. When you place then in WEB-INF, then you write your own Servlet (Controller) that inspects the URL and with some sort of logic, forward/redirects to a JSP.

A good security layer (probably based on a Filter) will implement security that will take care of both above cases. Because, do you really want your Default Servlet to be "invoked" by unauthorized folks?

From what I know, the Best Practice is to make a folder called "public" in your "WebContent" folder and put only the unsecure content there. Your Filter should inspect each and ever URL request to your server /* and act accordingly.

Also, another Best Practice is never let any URL end with ".jsp". Even something like "welcome" or "login" or "logout" should be handled by your own SecurityFilter + DisplayController

Example:

WebContent

--public
----css
------main.css
----images
------logo.png
----js
------common.js
--private  
----js
------ui_handler.js
--WEB-INF
----classes
----jsp
Mecon
  • 977
  • 1
  • 6
  • 17