How to restrict direct access to JSP files, only allow access via servlet?

[Anan]

How to restrict direct access to JSP files, but allow access only via
servlet?
Is it possible via .htaccess? If so, e.g. of a snippet on how to do
it? Any other ways? Thanks.

 

[Michael Borgwardt]

How to restrict direct access to JSP files, but allow access only via
servlet?

Use the servlet-mapping entries in web.xml to funnel all accesses to the
servlet(s).

 

[Ryan Stewart]

How to restrict direct access to JSP files, but allow access only via
servlet?
Is it possible via .htaccess? If so, e.g. of a snippet on how to do
it? Any other ways? Thanks.

Put all JSPs in WEB-INF.

 

[Alan Gutierrez]

Put all JSPs in WEB-INF.

That can't be a good idea. I've put data in WEB-INF, but I'd never
think to put JSP resources there. Is this a common practice?

 

[Ryan Stewart]

That can't be a good idea. I've put data in WEB-INF, but I'd never
think to put JSP resources there. Is this a common practice?

From "Code Conventions for the JavaServer Pages Technology Version 1.x
Language":
"Third, we use the term JSP fragment to refer to a JSP page that can be
included in another JSP page. ... JSP fragments can use either .jsp or .jspf
as a suffix, and should be placed either in /WEB-INF/jspf or with the rest
of the static content, respectively. JSP fragments that are not complete
pages should always use the .jspf suffix and should always be placed in
/WEB-INF/jspf."

http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

Granted it can be interpreted a couple of ways. When using Struts, the idea
is that all access to the application will go through Struts. Therefore,
there is no need for any public JSPs. And in a sense, every JSP is being
included, though not in another JSP.

 

[John C. Bollinger]

From "Code Conventions for the JavaServer Pages Technology Version 1.x
Language":
"Third, we use the term JSP fragment to refer to a JSP page that can be
included in another JSP page. ... JSP fragments can use either .jsp or .jspf
as a suffix, and should be placed either in /WEB-INF/jspf or with the rest
of the static content, respectively. JSP fragments that are not complete
pages should always use the .jspf suffix and should always be placed in
/WEB-INF/jspf."

http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

I think "JSP fragments can use either .jsp or .jspf as a suffix, and
should be placed either in /WEB-INF/jspf or with the rest of the static
content, respectively" mixes up the recommended locations for .jsp and
..jspf files. In particular, it is not consistent with the next sentence
that specifies that certain JSP fragments should both have the .jspf
extension and be located in /WEB-INF/jspf. As a result, I think the
convention that is being conveyed is to put .jsp files "with [...] the
static content", i.e. _not_ under WEB-INF.

Granted it can be interpreted a couple of ways.

Indeed. You can certainly disagree with my interpretation, but in
stipulating multiple possible interpretations you absolve the text in
question from having any authority with respect to the matter at hand.

When using Struts, the idea
is that all access to the application will go through Struts. Therefore,
there is no need for any public JSPs. And in a sense, every JSP is being
included, though not in another JSP.

That's well and good, but not relevant to where the .jsp files should be
located relative to the webapp root. I happen to agree with Alan that
JSPs that are complete pages and are used as such should not be placed
under WEB-INF. There are multiple mechanisms available for preventing
direct access to the JSPs; putting them under WEB-INF is unnecessary,
unconventional (according to my reading of the Sun convention), and
confusing.


John Bollinger
(e-mail address removed)

 

[Sudsy]

That can't be a good idea. I've put data in WEB-INF, but I'd never
think to put JSP resources there. Is this a common practice?

I put almost all application resources (which don't need to be accessed
directly by a client) under WEB-INF. I typically have have lib, jsp, dtd
and tld subdirectories. As to whether it's a common practice, I'd have
to pull some tomes off the bookshelf to be sure but I'm fairly certain
that my approach is the recommended one. Goodness knows, classes are
kept there...

 

[Ryan Stewart]

From "Code Conventions for the JavaServer Pages Technology Version 1.x
Language":
"Third, we use the term JSP fragment to refer to a JSP page that can be
included in another JSP page. ... JSP fragments can use either .jsp or
.jspf as a suffix, and should be placed either in /WEB-INF/jspf or with
the rest of the static content, respectively. JSP fragments that are not
complete pages should always use the .jspf suffix and should always be
placed in /WEB-INF/jspf."

http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

I think "JSP fragments can use either .jsp or .jspf as a suffix, and
should be placed either in /WEB-INF/jspf or with the rest of the static
content, respectively" mixes up the recommended locations for .jsp and
.jspf files. In particular, it is not consistent with the next sentence
that specifies that certain JSP fragments should both have the .jspf
extension and be located in /WEB-INF/jspf. As a result, I think the
convention that is being conveyed is to put .jsp files "with [...] the
static content", i.e. _not_ under WEB-INF.

1) JSP fragments that are not complete pages should always have a .jspf
extension and go in /WEB-INF/jspf. This is not inconsistent with the
previous statement. It is an enhancement of it. JSP fragments that are
complete pages may be named with .jsp or .jspf and may be placed in the jspf
folder or with other static content.

2) I agree that JSPs should generally go with other static content. This
specification actually makes no recommendation that I see, either explicit
or implied, as to where that should be, so I probably shouldn't have brought
it in here in the first place.

That's well and good, but not relevant to where the .jsp files should be
located relative to the webapp root.

It's completely relevant given the definition of a JSP fragment and where
said fragments are to be placed.

I happen to agree with Alan that JSPs that are complete pages and are
used as such should not be placed under WEB-INF. There are multiple
mechanisms available for preventing direct access to the JSPs; putting
them under WEB-INF is unnecessary, unconventional (according to my reading
of the Sun convention), and confusing.

Since this whole thread is supposed to be about preventing direct access to
JSPs, would you mind sharing the mechanisms you mentioned?

 

[John C. Bollinger]

Since this whole thread is supposed to be about preventing direct access to
JSPs, would you mind sharing the mechanisms you mentioned?

Some are configuration-dependent:
1) In an Apache/Tomcat setup, for instance, you can configure access
control in Apache so that requests for the JSPs is denied with your
choice of HTTP error response.
2) Specific servlet containers may offer access-control functionality
similar to (1).
3) As mentioned elsewhere in this thread, you can use servlet mappings
to map requests for JSPs to requests for the controller servlet (or for
an error page). This may not appropriate for JSPs to which you intend
to dispatch requests, however.

There is at least one mechanism that is completely portable across
containers supporting Servlet 2.3 and above:
4) Configure a simple filter to block or deflect external requests for
the JSPs while allowing requests to be dispatched to them internally.


John Bollinger
(e-mail address removed)