Sending a Redirect Directly from an Action Class
What are your thoughts on sending a redirect directly from an Action class: response.sendRedirect("/somePage.jsp?"); return null; There is a setRedirect(boolean redirect) in the ActionForward class that could be used for the same purpose (with a few extra lines of code and an entry in the strutsconfig.xml). Thanks. Mike __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
I have the following concerns whenever the redirect is used: * The statement response.sendRedirect("/somePage.jsp") will bind the codes statically to the underlying file system structures. So if someone moves the somePage.jsp to a different location, the codes are broken. * The JSP page somePage.jsp could not be protected by the standard security constraints. So it is recommended to use response.sendRedirect("/someAction.do") or a Filter, either way that provides security checking. Improper use of the redirect could make the security constraints over complicated as in an early discussion on how we redirect to restricted pages. * Use the redirect only when it is really needed. It needs extra CPU time and network resources than just forward. Regarding to the last concern, I have a question: what business requirements that need the redirect within a web application? Using the redirect across web applications or web sites is reasonable as well as when we dynamically build hyper links. A delay at client side? Any more ideas? Jing Netspread Carrier http://www.netspread.com - Original Message - From: "Mike Duffy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 28, 2003 11:27 AM Subject: Sending a Redirect Directly from an Action Class > What are your thoughts on sending a redirect directly from an Action > class: > > response.sendRedirect("/somePage.jsp?"); > return null; > > There is a setRedirect(boolean redirect) in the ActionForward class > that could be used for the same purpose (with a few extra lines of > code and an entry in the strutsconfig.xml). > > Thanks. > > Mike > > > __ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
> -Original Message- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: June 28, 2003 10:28 AM > To: Struts Users Mailing List > Subject: Re: Sending a Redirect Directly from an Action Class > > > I have the following concerns whenever the redirect is used: > > * The statement response.sendRedirect("/somePage.jsp") >will bind the codes statically to the underlying file system >structures. So if someone moves the somePage.jsp to >a different location, the codes are broken. Yes, there's nothing gained by hard coding the redirect in the action class and it's easier and more flexible to use redirect=true on an ActionForward. > > * The JSP page somePage.jsp could not be protected >by the standard security constraints. So it is recommended >to use response.sendRedirect("/someAction.do") or >a Filter, either way that provides security checking. >Improper use of the redirect could make the security >constraints over complicated as in an early discussion on >how we redirect to restricted pages. > This is not true. When you redirect the client issues a new request which is subject to container managed security. (You can set up a rule to protect /somePage.jsp as easily as you can /someAction.do. When you *forward* a request, this happens within the container and does not trigger security rules. > * Use the redirect only when it is really needed. It needs >extra CPU time and network resources than just forward. > Technically true, because it does create an extra round-trip between client and server. But the overall effect is negligible. About as much as your user clicking on a link to go to another page and I think most servers should be able to handle that ;-) > Regarding to the last concern, I have a question: what > business requirements that need the redirect within > a web application? Using the redirect across web > applications or web sites is reasonable as well as when > we dynamically build hyper links. > > A delay at client side? Any more ideas? When you forward request the client URL does not change. This can cause situations where the URL displayed in the browser is inconsistent with what's displayed on the screen. It's useful to do a redirect at the end of some requests in order to reconcile the URL with the page that's displayed. For example, if my login form submits to /processLogin.do and then forwards to my home page, the browser URL will still display /processLogin.do. What I really want is for the browser to display the URL of my home page (say /index.do). So I issue a redirect, rather than forward to achieve this. So what? Well, for one thing, different URLs for the same page can confuse the user. Secondly, if the action was a long running one or updates the database and the user refereshes the screen after a forward it could cause the action to be re-run. I know, you can use tokens to prevent this, but then you get a situation where the user just wants to refresh the home page and ends up getting an error message that a form was submitted out of sequence! So, sometimes a redirect is the right thing to do, but for maximum flexibility it should be done using an ActionFoward with redirect set to true. Steve > > Jing > Netspread Carrier > http://www.netspread.com > > - Original Message ----- > From: "Mike Duffy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 28, 2003 11:27 AM > Subject: Sending a Redirect Directly from an Action Class > > > > What are your thoughts on sending a redirect directly from an Action > > class: > > > > response.sendRedirect("/somePage.jsp?"); > > return null; > > > > There is a setRedirect(boolean redirect) in the ActionForward class > > that could be used for the same purpose (with a few extra lines of > > code and an entry in the strutsconfig.xml). > > > > Thanks. > > > > Mike > > > > > > __ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, June 28, 2003 4:17 PM Subject: RE: Sending a Redirect Directly from an Action Class > > > > -Original Message- > > From: Jing Zhou [mailto:[EMAIL PROTECTED] > > Sent: June 28, 2003 10:28 AM > > To: Struts Users Mailing List > > Subject: Re: Sending a Redirect Directly from an Action Class > > > > > > I have the following concerns whenever the redirect is used: > > > > * The statement response.sendRedirect("/somePage.jsp") > >will bind the codes statically to the underlying file system > >structures. So if someone moves the somePage.jsp to > >a different location, the codes are broken. > > Yes, there's nothing gained by hard coding the redirect in the action class > and it's easier and more flexible to use redirect=true on an ActionForward. > > > > > * The JSP page somePage.jsp could not be protected > >by the standard security constraints. So it is recommended > >to use response.sendRedirect("/someAction.do") or > >a Filter, either way that provides security checking. > >Improper use of the redirect could make the security > >constraints over complicated as in an early discussion on > >how we redirect to restricted pages. > > > > This is not true. When you redirect the client issues a new request which is > subject to container managed security. (You can set up a rule to protect > /somePage.jsp as easily as you can /someAction.do. When you *forward* > a request, this happens within the container and does not trigger security > rules. If you means the new redirected request to the page /somePage.jsp is subject to container managed security because a custom action in the page perform the security checking, that is not called container manager security. It is the old Model 1 things. > > > * Use the redirect only when it is really needed. It needs > >extra CPU time and network resources than just forward. > > > > Technically true, because it does create an extra round-trip between client > and server. But the overall effect is negligible. About as much as your user > clicking on a link to go to another page and I think most servers should be > able to handle that ;-) > > > Regarding to the last concern, I have a question: what > > business requirements that need the redirect within > > a web application? Using the redirect across web > > applications or web sites is reasonable as well as when > > we dynamically build hyper links. > > > > A delay at client side? Any more ideas? > > When you forward request the client URL does not change. This can cause > situations where the URL displayed in the browser is inconsistent with > what's displayed on the screen. It's useful to do a redirect at the end of > some requests in order to reconcile the URL with the page that's displayed. > > For example, if my login form submits to /processLogin.do and then forwards > to my home page, the browser URL will still display /processLogin.do. What I > really want is for the browser to display the URL of my home page (say > /index.do). So I issue a redirect, rather than forward to achieve this. > > So what? Well, for one thing, different URLs for the same page can confuse > the user. Secondly, if the action was a long running one or updates the > database and the user refereshes the screen after a forward it could cause > the action to be re-run. I know, you can use tokens to prevent this, but > then you get a situation where the user just wants to refresh the home page > and ends up getting an error message that a form was submitted out of > sequence! It is a good example. I did heard some customers mentioned it somewhere. But displaying *right* URL on the address bar is a more client issue. Has any body tried to use Java scripts to change the URL to a desired string? For me, I just turn off the address bar. Of course, it is not a general solution to it. Any other examples? > > So, sometimes a redirect is the right thing to do, but for maximum > flexibility it should be done using an ActionFoward with redirect set to > true. > > Steve > > > > > Jing > > Netspread Carrier > > http://www.netspread.com > > > > - Original Message - > > From: "Mike Duffy" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, June 28, 2003 11:27 AM > > Subject: Sending a Redirect Directly from an Action Class > > > > > > > What are you
RE: Sending a Redirect Directly from an Action Class
> -Original Message- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: June 28, 2003 3:46 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Sending a Redirect Directly from an Action Class > > If you means the new redirected request to the page /somePage.jsp is > subject to container managed security because a custom action in the page > perform the security checking, that is not called container manager > security. > It is the old Model 1 things. > Nope. I mean container managed security, defined in web.xml > > It is a good example. I did heard some customers mentioned it somewhere. > But displaying *right* URL on the address bar is a more client issue. > Has any body tried to use Java scripts to change the URL to a desired > string? For me, I just turn off the address bar. Of course, it is not a > general solution to it. Any other examples? > Javascript and hiding the address bar are unneccesary, inelegant and are easily broken. By using a redirect you don't need to resort to such tactics. I don't think anyone has ever suggested that redirects should not be used. They're just another tool in the box. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, June 28, 2003 9:45 PM Subject: RE: Sending a Redirect Directly from an Action Class > > > -Original Message- > > From: Jing Zhou [mailto:[EMAIL PROTECTED] > > Sent: June 28, 2003 3:46 PM > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: Re: Sending a Redirect Directly from an Action Class > > > > > If you means the new redirected request to the page /somePage.jsp is > > subject to container managed security because a custom action in the page > > perform the security checking, that is not called container manager > > security. > > It is the old Model 1 things. > > > > Nope. I mean container managed security, defined in web.xml If you mean the page /somePage.jsp can be put under a security constraint in web.xml and you can redirect to it, that is not going to work in theory. This is the original point why the page can not be protected by the security constraint when the method response.sendRedirect("/somePage.jsp") is called and the call response.sendRedirect("/someAction.do") is one of solutions to it. > > > > > It is a good example. I did heard some customers mentioned it somewhere. > > But displaying *right* URL on the address bar is a more client issue. > > Has any body tried to use Java scripts to change the URL to a desired > > string? For me, I just turn off the address bar. Of course, it is not a > > general solution to it. Any other examples? > > > > Javascript and hiding the address bar are unneccesary, inelegant and are > easily broken. By using a redirect you don't need to resort to such tactics. > I don't think anyone has ever suggested that redirects should not be used. > They're just another tool in the box. You use it as you *need* it, not because it is another tool in the box. What I am searching for is some compelling business requirements that the redirect within a web application is *really* necessary. I hope some one could provide more hints. > > Steve > > Jing > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
> If you mean the page /somePage.jsp can be put under a security > constraint in web.xml and you can redirect to it, that is not > going to work in theory. This is the original point why the > page can not be protected by the security constraint when the method > response.sendRedirect("/somePage.jsp") is called and > the call response.sendRedirect("/someAction.do") is one > of solutions to it. You are mistaken. Container managed security can protect any resource in the web application, including JSPs. Please don't think I'm advocating calling JSPs directly - I'm not. But the reasons you shouldn't do not include anything to do with CMS. > You use it as you *need* it, not because it is another tool in the box. > What I am searching for is some compelling business requirements > that the redirect within a web application is *really* necessary. I hope > some one could provide more hints. That's what I meant. You use the tool that's most appropriate and redirects are *one* of many tools available to us. It would be wrong to use it for everything but it would be equally wrong to avoid using it where it is appropriate. Anyway this has strayed well away from Struts. The original question was whether to use sendRedirect in the action or use an ActionForward. That question has been answered. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, June 28, 2003 11:42 PM Subject: RE: Sending a Redirect Directly from an Action Class > > If you mean the page /somePage.jsp can be put under a security > > constraint in web.xml and you can redirect to it, that is not > > going to work in theory. This is the original point why the > > page can not be protected by the security constraint when the method > > response.sendRedirect("/somePage.jsp") is called and > > the call response.sendRedirect("/someAction.do") is one > > of solutions to it. > > You are mistaken. Container managed security can protect any resource in the > web application, including JSPs. Please don't think I'm advocating calling > JSPs directly - I'm not. But the reasons you shouldn't do not include > anything to do with CMS. When you said "This is not true." to the original concerns regarding response.sendRedirect("/somePage.jsp") method (which implies a direct call to the JSP page) and now you are not calling JSP directly, I don't get you. Of course, we know the security contraints can protect any thing. The problem is when a page is protected, the redirect will fail. > > > You use it as you *need* it, not because it is another tool in the box. > > What I am searching for is some compelling business requirements > > that the redirect within a web application is *really* necessary. I hope > > some one could provide more hints. > > That's what I meant. You use the tool that's most appropriate and redirects > are *one* of many tools available to us. It would be wrong to use it for > everything but it would be equally wrong to avoid using it where it is > appropriate. > > Anyway this has strayed well away from Struts. The original question was > whether to use sendRedirect in the action or use an ActionForward. That > question has been answered. > > Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
> When you said "This is not true." to the original concerns regarding > response.sendRedirect("/somePage.jsp") method (which implies a > direct call to the JSP page) and now you are not > calling JSP directly, I don't get you. Of course, we know the security > contraints can protect any thing. The problem is when a page is > protected, the redirect will fail. You said, "The JSP page somePage.jsp could not be protected by the standard security constraints." That's what I was referring to when I said, "This is not true." If you redirect to /someAction.do and that is protected by security contraints then the exact same error would occur aswhen you redirect to /somePage.jsp. So, purely in terms of security contraints, there is no difference between redirecting to the action or the jsp. As I said, that does not mean that I advocate directly accessing JSPs, just that the reasons for not doing so have nothing to do with redirects or container security. Hope that is clearer Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 12:33 AM Subject: RE: Sending a Redirect Directly from an Action Class > > > When you said "This is not true." to the original concerns regarding > > response.sendRedirect("/somePage.jsp") method (which implies a > > direct call to the JSP page) and now you are not > > calling JSP directly, I don't get you. Of course, we know the security > > contraints can protect any thing. The problem is when a page is > > protected, the redirect will fail. > > You said, "The JSP page somePage.jsp could not be protected by the standard > security constraints." That's what I was referring to when I said, "This is > not true." > > If you redirect to /someAction.do and that is protected by security > contraints then the exact same error would occur aswhen you redirect to > /somePage.jsp. So, purely in terms of security contraints, there is no > difference between redirecting to the action or the jsp. As I said, that > does not mean that I advocate directly accessing JSPs, just that the reasons > for not doing so have nothing to do with redirects or container security. When I talked the use of the redirect to /someAction.do, it doesn't imply it is protected by the security constraints. Normal pratice of the MVC model is that most of JSP pages should be protected while actions should not. Because actions have internal logics to perform security checking, that is a common sense (If you protect all of your actions, /*.do, how do your end users submit web forms? :-) Jing > > Hope that is clearer > > Steve > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
> When I talked the use of the redirect to /someAction.do, it > doesn't imply it is protected by the security constraints. > Normal pratice of the MVC model is that most of JSP pages should be > protected while actions should not. Because actions have internal > logics to perform security checking, that is a common sense > (If you protect all of your actions, /*.do, how > do your end users submit web forms? :-) It does imply that when the original question was not about different security methods. I assumed that as the question was not about security then the action would be protected in the same way as the jsp otherwise the discussion, in the context of redirection, is meaningless. I could equally ask why you don't just programme the whole thing in Fortran, but that would be equally tangential to the original question :-) Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
Here is my original concerns regarding to the response.sendRedirect("/somePage.jsp"): >> >> * The JSP page somePage.jsp could not be protected >>by the standard security constraints. So it is recommended >>to use response.sendRedirect("/someAction.do") or >>a Filter, either way that provides security checking. >>Improper use of the redirect could make the security >>constraints over complicated as in an early discussion on >>how we redirect to restricted pages. >> And the following is your response: > This is not true. When you redirect the client issues a new request which is > subject to container managed security. Form my message, how do you conclude I am suggesting that the "/someAction.do" is protected under a security constraint? You added an assumption to my message and then claimed it "not true". Again, the idea that "/someAction.do" is protected is funny. I never thought that. Jing - Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 2:21 AM Subject: RE: Sending a Redirect Directly from an Action Class > > When I talked the use of the redirect to /someAction.do, it > > doesn't imply it is protected by the security constraints. > > Normal pratice of the MVC model is that most of JSP pages should be > > protected while actions should not. Because actions have internal > > logics to perform security checking, that is a common sense > > (If you protect all of your actions, /*.do, how > > do your end users submit web forms? :-) > > It does imply that when the original question was not about different > security methods. I assumed that as the question was not about security then > the action would be protected in the same way as the jsp otherwise the > discussion, in the context of redirection, is meaningless. > > I could equally ask why you don't just programme the whole thing in Fortran, > but that would be equally tangential to the original question :-) > > Steve > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
The statement, "The JSP page somePage.jsp could not be protected by the standard security constraints." is incorrect. This discussion no longer has anything to do with Struts. Unless you disagree with either of these points can we now drop it, please? Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 10:09 AM Subject: RE: Sending a Redirect Directly from an Action Class > The statement, "The JSP page somePage.jsp could not be protected by the > standard security constraints." is incorrect. You recognized the discussion context is on the concerns of the redirect to the JSP page /somePage.jsp, right? (Shoud I bring out the orignal text again?) Let me ask you, if you put the page under a standard security constraint, how can you perform a redirect to that page sucessfully? Taking a statement out of its contexts is not very professional. > > This discussion no longer has anything to do with Struts. However, it has something to do with the Struts users, because you are misleading the Struts users when you said "not true" or "is incorrect" to the original text. > > Unless you disagree with either of these points can we now drop it, please? You changed your arguments from *assuming* the action is protected to the statement you mentioned above, could you drop the tactics, please? > > Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
Redirecting to a page has *nothing* to do with security constraints. If you have the necessary authority to that page then the page will be displayed without error. If you do not have the authority then an error will be generated. However, this does not mean that the redirect has failed. The redirect worked but the redirect target generated an error which, in any decent application, will be handled and the user will be presented with a meaningful error page or logon page. So, the JSP *can* in fact be protected by container managed security. I have never said this is the *best* way of doing things but your assertion that the JSP page could not be protected by standard security constraints is just plain wrong. Steve > -Original Message- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: June 29, 2003 11:12 AM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Sending a Redirect Directly from an Action Class > > > > - Original Message - > From: "Steve Raeburn" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Sunday, June 29, 2003 10:09 AM > Subject: RE: Sending a Redirect Directly from an Action Class > > > > The statement, "The JSP page somePage.jsp could not be protected by the > > standard security constraints." is incorrect. > > You recognized the discussion context is on the concerns of the > redirect to > the > JSP page /somePage.jsp, right? (Shoud I bring out the orignal text again?) > Let me ask you, if you put the page under a standard security constraint, > how can you perform a redirect to that page sucessfully? > Taking a statement out of its contexts is not very professional. > > > > > This discussion no longer has anything to do with Struts. > > However, it has something to do with the Struts users, > because you are misleading the Struts users when you said "not true" > or "is incorrect" to the original text. > > > > > Unless you disagree with either of these points can we now drop it, > please? > > You changed your arguments from *assuming* the action is protected > to the statement you mentioned above, could you drop the tactics, please? > > > > > Steve > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 1:50 PM Subject: RE: Sending a Redirect Directly from an Action Class > Redirecting to a page has *nothing* to do with security constraints. > > If you have the necessary authority to that page then the page will be > displayed without error. If you do not have the authority then an error will > be generated. However, this does not mean that the redirect has failed. The > redirect worked but the redirect target generated an error which, in any > decent application, will be handled and the user will be presented with a > meaningful error page or logon page. > > So, the JSP *can* in fact be protected by container managed security. I have > never said this is the *best* way of doing things but your assertion that > the JSP page could not be protected by standard security constraints is just > plain wrong. > > Steve > > > -Original Message- > > From: Jing Zhou [mailto:[EMAIL PROTECTED] > > Sent: June 29, 2003 11:12 AM > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: Re: Sending a Redirect Directly from an Action Class > > > > > > > > - Original Message - > > From: "Steve Raeburn" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Sunday, June 29, 2003 10:09 AM > > Subject: RE: Sending a Redirect Directly from an Action Class > > > > > > > The statement, "The JSP page somePage.jsp could not be protected by the > > > standard security constraints." is incorrect. > > > > You recognized the discussion context is on the concerns of the > > redirect to > > the > > JSP page /somePage.jsp, right? (Shoud I bring out the orignal text again?) > > Let me ask you, if you put the page under a standard security constraint, > > how can you perform a redirect to that page sucessfully? > > Taking a statement out of its contexts is not very professional. > > > > > > > > This discussion no longer has anything to do with Struts. > > > > However, it has something to do with the Struts users, > > because you are misleading the Struts users when you said "not true" > > or "is incorrect" to the original text. > > > > > > > > Unless you disagree with either of these points can we now drop it, > > please? > > > > You changed your arguments from *assuming* the action is protected > > to the statement you mentioned above, could you drop the tactics, please? > > > > > > > > Steve > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
It looks to me some more *assumed* assumptions are added to achieve your *best* way. The *easiest* way in my assumption is that no one has direct access to the JSP pages in the security constraints. When assumptions could be added arbitrarily, it is hard for anyone to produce forever true statements :-) Jing - Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 1:50 PM Subject: RE: Sending a Redirect Directly from an Action Class > Redirecting to a page has *nothing* to do with security constraints. > > If you have the necessary authority to that page then the page will be > displayed without error. If you do not have the authority then an error will > be generated. However, this does not mean that the redirect has failed. The > redirect worked but the redirect target generated an error which, in any > decent application, will be handled and the user will be presented with a > meaningful error page or logon page. > > So, the JSP *can* in fact be protected by container managed security. I have > never said this is the *best* way of doing things but your assertion that > the JSP page could not be protected by standard security constraints is just > plain wrong. > > Steve > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
> The *easiest* way in my assumption is that no one has direct access to the JSP pages in the security constraints. Actually the easiest way is to place JSPs under WEB-INF but that was not what we were talking about. I'm not making assumption in that you flatly said that the JSP could not be protected by standard security constraints and I pointed out that it could. You may have misstated what you meant or simply misunderstood how it works, but what you actually wrote was factually incorrect. In regard to your previous comment, 'unprofessional' would have been all the things I re-phrased to avoid giving offence. Perhaps you should consider that yourself, next time. I'm not getting anything out of this now and I'm sure others have more than enough information about the subject so let's consider the matter closed. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 3:16 PM Subject: RE: Sending a Redirect Directly from an Action Class > > The *easiest* way in my assumption is that no one has direct access to the > JSP pages in the security constraints. > > Actually the easiest way is to place JSPs under WEB-INF but that was not > what we were talking about. That is an old practice and it may not be supported by all vendors in all versions of their server software. > > I'm not making assumption in that you flatly said that the JSP could not be > protected by standard security constraints and I pointed out that it could. > You may have misstated what you meant or simply misunderstood how it works, > but what you actually wrote was factually incorrect. > > In regard to your previous comment, 'unprofessional' would have been all the > things I re-phrased to avoid giving offence. Perhaps you should consider > that yourself, next time. When making recommendations, I am assuming the best practices of the MVC models for simplicity of the statements. They include no protections on actions and no direct accesses to JSP pages. They are clear concepts to every morden MVC expert. Later you added your assumptions to protect actions, then added your assumptions to use the security constraints in old ways which are suitable for the Model 1 things. As to why the ways you described to use the security constraints are junked ideas, I will discuss sometimes later. It looks to me you don't understand they get dumped in morden MVC models, so you use them or recommend them in your *professional* ways. > > I'm not getting anything out of this now and I'm sure others have more than > enough information about the subject so let's consider the matter closed. > > Steve > > Jing > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
Look, I am trying to let this go. But you insist on throwing out statements that may mislead others. Placing JSPs under WEB-INF is an established best practice and was supported under servlet API 2.2 where it was allowed and reinforced under Servlet API 2.3 where it was expressly permitted. It is my understanding that a container that claims to support Servlet API 2.3 must permit this, though I don't know if all do yet. Your MVC best practices apparently include hiding the address bar from users and relying on JavaScript to refresh the URL where a simple redirect would suffice. I assume this leads to excellent usability on diverse user-agents including screen readers and devices that don't support JavaScript. You are perfectly welcome to express your views on current best practise but please don't confuse what is best practise with what will work. I have repeated ad-nauseum that though I was not advocating direct access of JSPs a redirect to the JSP would work, regardless of the security constraints in place, in this particular example. Keep digging Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
- Original Message - From: "Steve Raeburn" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, June 29, 2003 4:45 PM Subject: RE: Sending a Redirect Directly from an Action Class > Look, I am trying to let this go. But you insist on throwing out statements > that may mislead others. On the contrary, every time you *assume*, it introduces a misleading thing. > > Placing JSPs under WEB-INF is an established best practice and was supported > under servlet API 2.2 where it was allowed and reinforced under Servlet API > 2.3 where it was expressly permitted. It is my understanding that a > container that claims to support Servlet API 2.3 must permit this, though I > don't know if all do yet. > > Your MVC best practices apparently include hiding the address bar from users > and relying on JavaScript to refresh the URL where a simple redirect would > suffice. I assume this leads to excellent usability on diverse user-agents > including screen readers and devices that don't support JavaScript. Now I see another *assume*. Your ability to assume is overly strong :-) Redirects can be done, address bars can be hidden or shown with desired URLs, and non-JavaScript agents can be supported, all in the best practices of the morden MVC models. Do not *assume* to stop misleading. Open your mind to accept new things. You are welcome to ask questions if you are unsure for somethings. Jing Netspread Carrier http://www.netspread.com > > You are perfectly welcome to express your views on current best practise but > please don't confuse what is best practise with what will work. I have > repeated ad-nauseum that though I was not advocating direct access of JSPs a > redirect to the JSP would work, regardless of the security constraints in > place, in this particular example. > > Keep digging > > Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sending a Redirect Directly from an Action Class
*Sigh* This discussion is now closed. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sending a Redirect Directly from an Action Class
Sorry to horn in on a conversation that is "closed", but I do not to correct a mis-statement in the thread below. On Sun, 29 Jun 2003, Jing Zhou wrote: > From: "Steve Raeburn" <[EMAIL PROTECTED]> > > > Actually the easiest way is to place JSPs under WEB-INF but that was not > > what we were talking about. > > That is an old practice and it may not be supported by all vendors in all > versions of their server software. This turns out not to be the real issue. Every container I'm familiar with correctly disallows direct access to a JSP page (from a client request) stored under /WEB-INF. If they did not, they would be explictly breaking requirements in the Servlet Specification, Section 9.5: No file in the WEB-INF directory may be served directly to a client by the container. The problem for applications based on Struts (and anyone else who used RequestDispatcher.forward()) is that not all containers allowed you to do a RequestDispatcher.forward() to a JSP page stored in WEB-INF. The arguments against allowing this were tenuous in previous versions of the servlet spec, but as of version 2.4 (currently in Proposed Final Draft) it is being made very clear by the following addition to Section 9.5: However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the servlet context, and may be exposed using the RequestDispatcher calls. So, any Servlet 2.4 or later container that disallows such usage are going to be in clear violation of the spec. Smart servlet container vendors will understand that this was always the intent (even though it wasn't explicitly spelled out < 2.4), and will fix their current container implementations as well. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]