Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / June 2007

Tip: Looking for answers? Try searching our database.

prevent direct access to JSP

Thread view: 
Robert Watkins - 20 Jun 2007 16:11 GMT
Okay, so we're upgrading to Tomcat 6, and we've encountered a difficulty.

In order to keep URLs consistent (for simpler log parsing and for
cosmetic reasons) the idea is to have a servlet as the controller and a
JSP for the display, but only ever to have the servlet URL visible to the
user. As such:

 servlet:  /path/servlet
 jsp:      /path/page.jsp

The main access is through the servlet, and at the appropriate moment the
user is forwarded to the JSP, using:

 RequestDispatcher dispatcher =
   request.getRequestDispatcher("/path/page.jsp");
 dispatcher.forward(request, response);

Using Tomcat 5.0, I was able, in the JSP, to use (nothing really hard
coded):

 if (request.getRequestURL().toString().indexOf("page.jsp") != -1) {
   response.sendRedirect("/path/servlet");
   return;
 }

... because the request URL was that of the servlet from which the
forward was called. In Tomcat 6, however, the request URL is that of the
forward target.

Reading the API, it looks as if this should have been the behaviour all
along, but that's moot. The question is: How can I prevent direct access
to the JSP in another way?

Cheers,
-- Robert
Tom Hawtin - 20 Jun 2007 16:36 GMT
> Reading the API, it looks as if this should have been the behaviour all
> along, but that's moot. The question is: How can I prevent direct access
> to the JSP in another way?

Put the JSP under /WEB-INF/.

Tom Hawtin
Robert Watkins - 20 Jun 2007 16:46 GMT
>> Reading the API, it looks as if this should have been the behaviour
>> all along, but that's moot. The question is: How can I prevent direct
[quoted text clipped - 3 lines]
>
> Tom Hawtin

Hmmm -- must be something I'm missing, because I get a 404 error:

 The requested resource (/path/page.jsp) is not available.

Does the forward path have to change?

-- Robert
Lew - 20 Jun 2007 18:17 GMT
Tom Hawtin <usenet@tackline.plus.com> wrote in
>> Put the JSP under /WEB-INF/.
>>
>> Tom Hawtin

> Hmmm -- must be something I'm missing, because I get a 404 error:
>
>   The requested resource (/path/page.jsp) is not available.

It is for the correct value of 'path'.

> Does the forward path have to change?

It has to include the WEB-INF/ path node.

Either:

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "/application/WEB-INF/page.jsp" );

or just

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "WEB-INF/page.jsp" );

I usually use relative paths (always down from current, never up).

BTW, if you had provided an SSCCE instead of paraphrasing as 'path',
'page.jsp', etc., you'd have had a much clearer question.  Notice how
hand-waving over 'path' actually obscured the issue?

Signature

Lew

Robert Watkins - 20 Jun 2007 21:02 GMT
> Tom Hawtin <usenet@tackline.plus.com> wrote in
>>> Put the JSP under /WEB-INF/.
[quoted text clipped - 4 lines]
>
> It has to include the WEB-INF/ path node.

Thanks for this final piece of the puzzle. All is working now, with the
desired effect.

-- Robert
Lew - 20 Jun 2007 19:24 GMT
>>> Reading the API, it looks as if this should have been the behaviour
>>> all along, but that's moot. The question is: How can I prevent direct
[quoted text clipped - 10 lines]
>
> -- Robert
Tom Hawtin <usenet@tackline.plus.com> wrote in
>> Put the JSP under /WEB-INF/.
>>
>> Tom Hawtin

> Hmmm -- must be something I'm missing, because I get a 404 error:
>
>   The requested resource (/path/page.jsp) is not available.

It is for the correct value of 'path'.

> Does the forward path have to change?

It has to include the WEB-INF/ path node.

Either:

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "/application/WEB-INF/page.jsp" );

or just

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "WEB-INF/page.jsp" );

I usually use relative paths (always down from current, never up).

BTW, if you had provided an SSCCE instead of paraphrasing as 'path',
'page.jsp', etc., you'd have had a much clearer question.  Notice how
hand-waving over 'path' actually obscured the issue?

Signature

Lew

Lew - 20 Jun 2007 19:37 GMT
>>> Reading the API, it looks as if this should have been the behaviour
>>> all along, but that's moot. The question is: How can I prevent direct
>>> access to the JSP in another way?

Tom Hawtin <usenet@tackline.plus.com> wrote in
>> Put the JSP under /WEB-INF/.

> Hmmm -- must be something I'm missing, because I get a 404 error:
>
>   The requested resource (/path/page.jsp) is not available.

It is for the correct value of 'path'.

> Does the forward path have to change?

It has to include the WEB-INF/ path node.

Either:

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "/application/WEB-INF/page.jsp" );

or just

 RequestDispatcher dispatcher =
    request.getRequestDispatcher( "WEB-INF/page.jsp" );

I usually use relative paths (always down from current, never up).

BTW, if you had provided an SSCCE instead of paraphrasing as 'path',
'page.jsp', etc., you'd have had a much clearer question.  Notice how
hand-waving over 'path' actually obscured the issue?

Signature

Lew



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.