You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jens Rehpöhler <je...@rehpoehler.de> on 2001/02/28 13:54:14 UTC
Why should you call JSP pages directly?
Hi all,
I'm watching this list quite a while and wondered why so
many people try to call there JSP pages directly from the
browser. In my understanding of the MVC pattern all requests
to your web application must be handled from the controller
servlet (ActionServlet). The only JSP page which could be
called directly is the start page of your application, in
most cases called index.jsp.
By calling the JSP directly you don't seperate the view
completly from the logic. One bad example is the
struts-example application. Here, the user authentication is
done in every JSP page by a tag called <app:checkLogon/>. In
my opinion the user authentication is absolutly LOGIC and
not VIEW. So it should be handled in the controller
(ActionServlet).
Other problems mentioned in this list are forms with
predefined values, which can't be handled without an Action
wich populates a bean. I think this isn't a "bug" but a
feature. Here you are forced to use the MVC pattern.
Maybe I'm a bit to restrictive in the use of the MVC
pattern, so I'm very pleased to here why it is a good idea
to call your JSP directly without a call to the
ActionServlet.
Jens
Re: HTTPClient vs java.net.URLConnection
Posted by Incze Lajos <in...@mail.matav.hu>.
On Thu, Mar 01, 2001 at 06:22:36PM -0600, Eric wrote:
> I was using HTTPClient, but I then switched to the com.mortbay.HTTP
> library (it comes with one of their products or something i believe).
> I forget why I did so, but I think it had something to do with
> limitations in dealing with filenames in HTTPClient. I advise you to
> compare the two.
>
> eric.
You can test the "tea" project's http package, too. It has interesting
ideas in a couple of fields, too. (opensource.go.com, some apache style
license). incze
Re: HTTPClient vs java.net.URLConnection
Posted by Eric <ej...@ir.iit.edu>.
I was using HTTPClient, but I then switched to the com.mortbay.HTTP
library (it comes with one of their products or something i believe).
I forget why I did so, but I think it had something to do with
limitations in dealing with filenames in HTTPClient. I advise you to
compare the two.
eric.
On Thu, Mar 01, 2001 at 02:53:09PM -0500, Maya Muchnik wrote:
> Hi,
> Does anyone use HTTPClient? What do you think about it? I have got this link several
> minutes ago.
> As its document said, in HTTPClient you can set timeout for response, pipelining of
> request. Source code is available. It includes the source code for parsing the
> multiPartRequest.
>
> HTTPClient can find at:
> http://www.innovation.ch/java/HTTPClient/
>
>
>
--
_____ _
| ____|(_) http://ir.iit.edu/~ej
| _| | | Page me via ICQ at
| |___ | | http://wwp.mirabilis.com/19022931
|______/ | or by mailing 19022931@pager.mirabilis.com
|__/
HTTPClient vs java.net.URLConnection
Posted by Maya Muchnik <mm...@pumatech.com>.
Hi,
Does anyone use HTTPClient? What do you think about it? I have got this link several
minutes ago.
As its document said, in HTTPClient you can set timeout for response, pipelining of
request. Source code is available. It includes the source code for parsing the
multiPartRequest.
HTTPClient can find at:
http://www.innovation.ch/java/HTTPClient/
Re: Why should you call JSP pages directly?
Posted by Incze Lajos <in...@mail.matav.hu>.
> I have had quite a few problems relating to this kind of thing - if you
> setup your login page as the "welcome" page, or indeed if the user
> accesses the login page directly, the container has no way of knowing
> where to go next after submitting the name and password to the
> j_security_check. We've been finding that JRun just hangs in this case.
> I reckon it would be preferable if the default was to go *to* the
> welcome page after a login with no previous cached request.
>
> Any ideas on ways of circumventing this type of problem? I was
> previously submitting the logon information to an Action class and
> either overwriting or inserting the "requested page" information which
> was stored in the session, and then forwarding to j_security_check. But
> this is a bit flaky and not very portable.
>
> cheers,
>
> Luke.
>
I've made something like this (in tomcat 3):
-- at the start of the login page:
<%
if( request.getRemoteUser( ) != null || session.isNew( ) ) {
response.sendRedirect( "/app/actions/main.do" );
return;
}
%>
--
It had many workaroungs ( e.g. getPrincipal was buggy, the main page
could not be placed in the guarded zone, that's why the actions
directory) and worked hazardously, but don't know why.
It redirects the request to the guarded main action
if this is a fresh session or the user was already in. After the
redirect the container traps the request again but has an address
to forward to after authentication. Anyway, the welcome page method
Craig mentioned I think supposes you were using your own
authentication, not container managed. incze
Re: Why should you call JSP pages directly?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Luke Taylor wrote:
> "Craig R. McClanahan" wrote:
> >
> > Chris Bartley wrote:
> >
> > > This thread seems to have gone off-topic a bit. What about Jens' original question about why ALL requests don't go through ActionServlet?:
> > >
> >
> > Ideally, that's what happens. Unfortunately, there are some practical realities that get in the way:
> >
> > * What about your welcome page? Usually, you want a URL like this:
> > http://myhost/myapp
> > to work, which will call up the index.html or index.jsp page. One approach
> > to this is to configure the URI of your login page as the "welcome" page
> > for the app, using the <welcome-file> element in web.xml.
> >
>
> I have had quite a few problems relating to this kind of thing - if you
> setup your login page as the "welcome" page, or indeed if the user
> accesses the login page directly, the container has no way of knowing
> where to go next after submitting the name and password to the
> j_security_check. We've been finding that JRun just hangs in this case.
> I reckon it would be preferable if the default was to go *to* the
> welcome page after a login with no previous cached request.
>
If you are using the form-based login mechanism supported by your servlet container, you would generally make the welcome page that you display to
logged in users be the "welcome file" for this webapp. The form login page would never be explicitly referenced (by the user) at all -- the
container will use it automatically the first time that your user attempts to access a protected page.
>
> Any ideas on ways of circumventing this type of problem? I was
> previously submitting the logon information to an Action class and
> either overwriting or inserting the "requested page" information which
> was stored in the session, and then forwarding to j_security_check. But
> this is a bit flaky and not very portable.
>
You are definitely going to have problems trying to "intercept" the login information and then forward to "j_security_check". For example, this
will fail in Tomcat 4.0, because it only recognizes "j_security_check" *if* the container did the redirect to the form login page.
Think of the pages you declare for <form-login-page> and <form-error-page> as part of the container, and not as part of your application.
>
> cheers,
>
> Luke.
>
> --
> Luke Taylor.
> PGP Key ID: 0x57E9523C
Craig
Re: Why should you call JSP pages directly?
Posted by Luke Taylor <ne...@freesurf.ch>.
"Craig R. McClanahan" wrote:
>
> Chris Bartley wrote:
>
> > This thread seems to have gone off-topic a bit. What about Jens' original question about why ALL requests don't go through ActionServlet?:
> >
>
> Ideally, that's what happens. Unfortunately, there are some practical realities that get in the way:
>
> * What about your welcome page? Usually, you want a URL like this:
> http://myhost/myapp
> to work, which will call up the index.html or index.jsp page. One approach
> to this is to configure the URI of your login page as the "welcome" page
> for the app, using the <welcome-file> element in web.xml.
>
I have had quite a few problems relating to this kind of thing - if you
setup your login page as the "welcome" page, or indeed if the user
accesses the login page directly, the container has no way of knowing
where to go next after submitting the name and password to the
j_security_check. We've been finding that JRun just hangs in this case.
I reckon it would be preferable if the default was to go *to* the
welcome page after a login with no previous cached request.
Any ideas on ways of circumventing this type of problem? I was
previously submitting the logon information to an Action class and
either overwriting or inserting the "requested page" information which
was stored in the session, and then forwarding to j_security_check. But
this is a bit flaky and not very portable.
cheers,
Luke.
--
Luke Taylor.
PGP Key ID: 0x57E9523C
Re: Why should you call JSP pages directly?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jens Rehpöhler wrote:
> Hello Craig,
>
> "Craig R. McClanahan" wrote:
>
> > * What about bookmarks? You have to be ready for the fact that users
> > are going to *try* this, even if you do not want them to. Alternatives have
> > been presented to protect JSP pages from this kind of access.
>
> I think with a clean design you can even allow bookmarking of your actions (*.do), though it could make things much more complicated :-)
>
> > * If you are switching from one view to another view (with no model manipulation),
> > I cannot see that much difficulty in linking from one JSP page directly to
> > another, but this is not particularly common.
>
> This is a really good example, which answers my question. But should you really allow this, if you think about the problems of bookmarking pages
> as you mentioned above? All in all it seems to be a kind of philosophy if you use links to your JSPs or not.
>
> I will stay at my "restrictive" use of the MVC pattern and will not use direct links to the JSP's of the web application. One advantage is, that
> you can easily change the pages to forward to in the struts-config.xml or dynamically in the perform() method without changing any links in your
> application, and the bookmarks a user had set can't get broken by changing the JSP.
>
Don't get me wrong -- I agree with your preference for always going through the controller. I just wanted to point out that there was a legitimate
use case where bypassing it would not cause problems. But, as you point out, that relates to how the application creates hyperlinks to itself, not
to what the user does.
>
> Jens
Craig
Re: Why should you call JSP pages directly?
Posted by Jens Rehpöhler <je...@rehpoehler.de>.
Hello Craig,
"Craig R. McClanahan" wrote:
> * What about bookmarks? You have to be ready for the fact that users
> are going to *try* this, even if you do not want them to. Alternatives have
> been presented to protect JSP pages from this kind of access.
I think with a clean design you can even allow bookmarking of your actions (*.do), though it could make things much more complicated :-)
> * If you are switching from one view to another view (with no model manipulation),
> I cannot see that much difficulty in linking from one JSP page directly to
> another, but this is not particularly common.
This is a really good example, which answers my question. But should you really allow this, if you think about the problems of bookmarking pages
as you mentioned above? All in all it seems to be a kind of philosophy if you use links to your JSPs or not.
I will stay at my "restrictive" use of the MVC pattern and will not use direct links to the JSP's of the web application. One advantage is, that
you can easily change the pages to forward to in the struts-config.xml or dynamically in the perform() method without changing any links in your
application, and the bookmarks a user had set can't get broken by changing the JSP.
Jens
Re: Why should you call JSP pages directly?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Chris Bartley wrote:
> This thread seems to have gone off-topic a bit. What about Jens' original question about why ALL requests don't go through ActionServlet?:
>
Ideally, that's what happens. Unfortunately, there are some practical realities that get in the way:
* What about your welcome page? Usually, you want a URL like this:
http://myhost/myapp
to work, which will call up the index.html or index.jsp page. One approach
to this is to configure the URI of your login page as the "welcome" page
for the app, using the <welcome-file> element in web.xml.
* What about bookmarks? You have to be ready for the fact that users
are going to *try* this, even if you do not want them to. Alternatives have
been presented to protect JSP pages from this kind of access.
* If you are switching from one view to another view (with no model manipulation),
I cannot see that much difficulty in linking from one JSP page directly to
another, but this is not particularly common.
In a servlet 2.3 environment, you will be able to enforce things like going through the controller using the Filter facility. Until then,
though, we have to deal with issues like those listed above.
Craig
>
> Jens Rehpöhler wrote:
> > I'm watching this list quite a while and wondered why so
> > many people try to call there JSP pages directly from the
> > browser. In my understanding of the MVC pattern all requests
> > to your web application must be handled from the controller
> > servlet (ActionServlet). The only JSP page which could be
> > called directly is the start page of your application, in
> > most cases called index.jsp.
> >
> > By calling the JSP directly you don't seperate the view
> > completly from the logic. One bad example is the
> > struts-example application. Here, the user authentication is
> > done in every JSP page by a tag called <app:checkLogon/>. In
> >
> > my opinion the user authentication is absolutly LOGIC and
> > not VIEW. So it should be handled in the controller
> > (ActionServlet).
> >
> > <snip>
> >
> > Maybe I'm a bit to restrictive in the use of the MVC
> > pattern, so I'm very pleased to here why it is a good idea
> > to call your JSP directly without a call to the
> > ActionServlet.
>
> It seems (to me) that, in Struts, only form submissions follow MVC. Or do i have it all wrong?
>
> thanks,
>
> chris
Re: Why should you call JSP pages directly?
Posted by Chris Bartley <Ch...@healthstream.com>.
This thread seems to have gone off-topic a bit. What about Jens' original question about why ALL requests don't go through ActionServlet?:
Jens Rehpöhler wrote:
> I'm watching this list quite a while and wondered why so
> many people try to call there JSP pages directly from the
> browser. In my understanding of the MVC pattern all requests
> to your web application must be handled from the controller
> servlet (ActionServlet). The only JSP page which could be
> called directly is the start page of your application, in
> most cases called index.jsp.
>
> By calling the JSP directly you don't seperate the view
> completly from the logic. One bad example is the
> struts-example application. Here, the user authentication is
> done in every JSP page by a tag called <app:checkLogon/>. In
>
> my opinion the user authentication is absolutly LOGIC and
> not VIEW. So it should be handled in the controller
> (ActionServlet).
>
> <snip>
>
> Maybe I'm a bit to restrictive in the use of the MVC
> pattern, so I'm very pleased to here why it is a good idea
> to call your JSP directly without a call to the
> ActionServlet.
It seems (to me) that, in Struts, only form submissions follow MVC. Or do i have it all wrong?
thanks,
chris
Re: Why should you call JSP pages directly?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Maya Muchnik wrote:
> One way, as I know, is to put all jsp, except index.jsp (or similar start up)
> under a protected directory. For Tomcat the secure directory is setup in web.xml
> (see web.xml for webapps/example, directory is example/jsp/security/protected).
> See also Tomcat instruction (I need refresh my memory myself).
>
Using container-managed security in this way is indeed portable.
A second portable mechanism (assuming that your container works correctly per the
servlet spec) is to put your JSP pages under WEB-INF. This works because the servlet
container is prohibited from allowing a client to access these JSP pages directly --
but it is entirely legal to do a RequestDispatcher.include() or
RequestDispatcher.forward() call to access them, as Struts does when you forward to
the appropriate page.
Craig
Re: Why should you call JSP pages directly?
Posted by Maya Muchnik <mm...@pumatech.com>.
One way, as I know, is to put all jsp, except index.jsp (or similar start up)
under a protected directory. For Tomcat the secure directory is setup in web.xml
(see web.xml for webapps/example, directory is example/jsp/security/protected).
See also Tomcat instruction (I need refresh my memory myself).
The other ways are in the email achieves:
Q, and A http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03611.html
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03684.html
(I am not sure that I know how to do this)
Q and A. http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03737.html
John Raley wrote:
> So how does one protect JSP's from direct invocation? Is there a
> server-independent way? (I'm using Tomcat, so that would also be good to
> know.)
>
> Maya Muchnik wrote:
>
> > Hello, Jens again,
> > I am totally agree with you, but to make it works somebody (a designer) must
> > to "protect" jsp files. Several people told me how to do this. About logic
> > JSP again it is the designer question. Of course, it is better to have JSP
> > only for view. Sometimes, it is difficult, and required everything to be
> > redesigned.
> > Maya
> >
> > Jens Rehpöhler wrote:
> >
> > > Hallo Maya,
> > >
> > > Maya Muchnik wrote:
> > >
> > > > Hi, Jens,
> > > > When I had asked a question about calling jsp directly, I was concerned,
> > > > that a user can see a directory or see a link (as I do) and call this
> > > > jsp directly from a browser query / input line. The user likes to
> > > > experiment.
> > > > That is all. He does not know what is a view jsp or logic jsp.
> > >
> > > That is the point: a user should never have the possibility to come in
> > > contact with a JSP. And a JSP should never contain any business logic.
> > >
> > > Jens
Re: Why should you call JSP pages directly?
Posted by John Raley <jo...@moonlight.com>.
So how does one protect JSP's from direct invocation? Is there a
server-independent way? (I'm using Tomcat, so that would also be good to
know.)
Maya Muchnik wrote:
> Hello, Jens again,
> I am totally agree with you, but to make it works somebody (a designer) must
> to "protect" jsp files. Several people told me how to do this. About logic
> JSP again it is the designer question. Of course, it is better to have JSP
> only for view. Sometimes, it is difficult, and required everything to be
> redesigned.
> Maya
>
> Jens Rehpöhler wrote:
>
> > Hallo Maya,
> >
> > Maya Muchnik wrote:
> >
> > > Hi, Jens,
> > > When I had asked a question about calling jsp directly, I was concerned,
> > > that a user can see a directory or see a link (as I do) and call this
> > > jsp directly from a browser query / input line. The user likes to
> > > experiment.
> > > That is all. He does not know what is a view jsp or logic jsp.
> >
> > That is the point: a user should never have the possibility to come in
> > contact with a JSP. And a JSP should never contain any business logic.
> >
> > Jens
Re: Why should you call JSP pages directly?
Posted by Maya Muchnik <mm...@pumatech.com>.
Hello, Jens again,
I am totally agree with you, but to make it works somebody (a designer) must
to "protect" jsp files. Several people told me how to do this. About logic
JSP again it is the designer question. Of course, it is better to have JSP
only for view. Sometimes, it is difficult, and required everything to be
redesigned.
Maya
Jens Rehpöhler wrote:
> Hallo Maya,
>
> Maya Muchnik wrote:
>
> > Hi, Jens,
> > When I had asked a question about calling jsp directly, I was concerned,
> > that a user can see a directory or see a link (as I do) and call this
> > jsp directly from a browser query / input line. The user likes to
> > experiment.
> > That is all. He does not know what is a view jsp or logic jsp.
>
> That is the point: a user should never have the possibility to come in
> contact with a JSP. And a JSP should never contain any business logic.
>
> Jens
Re: Why should you call JSP pages directly?
Posted by Jens Rehpöhler <je...@rehpoehler.de>.
Hallo Maya,
Maya Muchnik wrote:
> Hi, Jens,
> When I had asked a question about calling jsp directly, I was concerned,
> that a user can see a directory or see a link (as I do) and call this
> jsp directly from a browser query / input line. The user likes to
> experiment.
> That is all. He does not know what is a view jsp or logic jsp.
That is the point: a user should never have the possibility to come in
contact with a JSP. And a JSP should never contain any business logic.
Jens
Re: Why should you call JSP pages directly?
Posted by Maya Muchnik <mm...@pumatech.com>.
Hi, Jens,
When I had asked a question about calling jsp directly, I was concerned,
that a user can see a directory or see a link (as I do) and call this
jsp directly from a browser query / input line. The user likes to
experiment.
That is all. He does not know what is a view jsp or logic jsp.
Maya
Jens Rehpöhler wrote:
> Hi all,
>
> I'm watching this list quite a while and wondered why so
> many people try to call there JSP pages directly from the
> browser. In my understanding of the MVC pattern all requests
>
> to your web application must be handled from the controller
> servlet (ActionServlet). The only JSP page which could be
> called directly is the start page of your application, in
> most cases called index.jsp.
>
> By calling the JSP directly you don't seperate the view
> completly from the logic. One bad example is the
> struts-example application. Here, the user authentication is
>
> done in every JSP page by a tag called <app:checkLogon/>. In
>
> my opinion the user authentication is absolutly LOGIC and
> not VIEW. So it should be handled in the controller
> (ActionServlet).
>
> Other problems mentioned in this list are forms with
> predefined values, which can't be handled without an Action
> wich populates a bean. I think this isn't a "bug" but a
> feature. Here you are forced to use the MVC pattern.
>
> Maybe I'm a bit to restrictive in the use of the MVC
> pattern, so I'm very pleased to here why it is a good idea
> to call your JSP directly without a call to the
> ActionServlet.
>
> Jens
Re: Why should you call JSP pages directly?
Posted by Martin Smith <mf...@erols.com>.
Because it's simple?
Martin
Jens Rehpöhler wrote:
> Hi all,
>
> I'm watching this list quite a while and wondered why so
> many people try to call there JSP pages directly from the
> browser. In my understanding of the MVC pattern all requests
>
> to your web application must be handled from the controller
> servlet (ActionServlet). The only JSP page which could be
> called directly is the start page of your application, in
> most cases called index.jsp.
>
> By calling the JSP directly you don't seperate the view
> completly from the logic. One bad example is the
> struts-example application. Here, the user authentication is
>
> done in every JSP page by a tag called <app:checkLogon/>. In
>
> my opinion the user authentication is absolutly LOGIC and
> not VIEW. So it should be handled in the controller
> (ActionServlet).
>
> Other problems mentioned in this list are forms with
> predefined values, which can't be handled without an Action
> wich populates a bean. I think this isn't a "bug" but a
> feature. Here you are forced to use the MVC pattern.
>
> Maybe I'm a bit to restrictive in the use of the MVC
> pattern, so I'm very pleased to here why it is a good idea
> to call your JSP directly without a call to the
> ActionServlet.
>
> Jens