|
Thanks Art, This also explains why other webapps had securityproblems although I was sure 'authentication' took place before. Sometimes, when I used a forward() from another servlet directly to a controller.servlet I had same problem. When I changed the forward() to an html-form (I created 'index.html' for each app), which included an automatic submit to controller.servlet it worked. What I had to do then was change forward() to sendRedirect() and it should work. Ok, work was not lost, because I used the 'index.html' as an entry with a message that application is beïng loaded and userid/password can be asked when not previously entered. Thanks again. Patrick Goovaerts pgoovaerts@pandora.be TEL: 0032-3-6472715 GSM:0498610325 -----Oorspronkelijk bericht----- Van: java400-l-admin@midrange.com [mailto:java400-l-admin@midrange.com] Namens Art Smet Verzonden: woensdag 7 augustus 2002 20:29 Aan: java400-l@midrange.com Onderwerp: RE: HttpSession - problem Patrick, thanks now I understand your question better... .forward( ) and SendRedirect are mostly interchangeable, but my suggestion to change the . forward( ) to a SendRedirect( ) was intended only for the flow where the user just now authenticated on the current request, and then was forwarded to the controller.servlet, not just any .forward( ) vs. SendRedirect, sorry I was not clear on that. Here is what I think is happening which tries to explain why sometimes it works and sometimes it does not. 1) user authenticates. WebSphere does a "Set-Cookie xxxxx" for the response to set the authenication information, but these authentication cookies are not yet fully set as request Cookies yet. That wont happen until the response is sent back to the client (browser), which re-issues a requests containing the already set cookies with authentication values. 2) when user authenticates in step 1, the HTTP session maintained by WebSphere is now protected, and accessible only by the authenticated user 3) if a .forward( ) is issued to the controller.servlet, it tries to access the protected HTTP session. But the authentication check of the current user fails. Why? Because the request cookies are checked and there are no authentication values set there yet. The controller.servlet still gets a session under the covers, but a new one that has been cleared. 4) if a SendRedirect is issued instead to controller.servlet, then the request now has authentication cookies sent from the browser. As a result, the controller.servlet's access to the HTTP session is allowed, and it all works. 5) This is why I was persistent in asking about the working scenario, where jsp1 accessed the controller.servlet. Since jsp1 rendered a page to the client (browser), the submit flow to the controller.servlet meant a re- issued request was sent thereby setting the authentication cookies properly as part of the request, which allowed it to work. |---------+----------------------------> | | "Patrick | | | Goovaerts" | | | <pgoovaerts@pando| | | ra.be> | | | Sent by: java400-| | | l-admin@midrange.| | | com | | | | | | | | | 08/07/02 12:02 PM| | | Please respond to| | | java400-l | | | | |---------+----------------------------> >----------------------------------------------------------------------- ------------------------------------------------| | | | To: <java400-l@midrange.com> | | cc: | | Subject: RE: HttpSession - problem | | | | | >----------------------------------------------------------------------- ------------------------------------------------| Art, Jsp1 invokes the controller.servlet by using a form 'submit', triggered by a button. Here's the code: JSP1: ... <SCRIPT LANGUAGE="JavaScript" src="/FreightQuotations/javascript/openWindows.js"></SCRIPT> <SCRIPT LANGUAGE="Javascript" src="/FreightQuotations/javascript/actions.js"></SCRIPT> ... <FORM name="FormFQ" action="FQController" method=POST onSubmit="return testaction(action)"> <INPUT type=hidden name="screen" value="S1"> <INPUT type=hidden name="action" value=""> ... <INPUT type="button" style="font-size: 10px" tabindex="5" name="bList" value=" List " onClick="setaction(this.form, this)"> ... JAVASCRIPT ACTIONS.JS function testaction(paction) { if (paction.value == "") { alert("Please select an action-button below"); return false; } return true; } function setaction(form, button) { // if (button.name == "bList") {form.action.value = " List "} // if (button.name == "bAdd") {form.action.value = "Create"} // if (button.name == "bDelete") {form.action.value = "Delete"} // if (button.name == "bUpdate") {form.action.value = "Update"} // if (button.name == "bConfirm") {form.action.value = "Confirm"} // if (button.name == "bCopy") {form.action.value = " Copy "} form.action.value = button.value; form.submit(); } If course I do not ask you "how to change the . forward( ) to a sendRedirect( )" ! What I want to know is how to decide - when to use .forward() - when to use .sendRedirect() I can't imagine that one has to code .forward(), test it and when it doesn't work, change his code to .sendRedirect() As explained in previous mail, one of the reasons was a security issue while another reason was that the 2 (hidden)fields, used in JSP1 doesn't exist when launching controller.servlet directly. Patrick Goovaerts pgoovaerts@pandora.be TEL: 0032-3-6472715 GSM:0498610325 -----Oorspronkelijk bericht----- Van: java400-l-admin@midrange.com [mailto:java400-l-admin@midrange.com] Namens Art Smet Verzonden: woensdag 7 augustus 2002 17:12 Aan: java400-l@midrange.com Onderwerp: RE: HttpSession - problem >>When it works with: Html ==> Loginid ==> jsp1 ==> controller.servlet >>==> jsp1 or jsp2 .... which api does jsp1 use to call >>controller.servlet? There is more than one way for jsp1 to invoke the controller.servlet class, you did not say how your code (jsp1) does it. >>Also, did you try the earlier suggestion of using sendRedirect( ) api >>instead of .forward( ) to see if that helped at all? how do one decide which to choose: .forward() or sendRedirect() ? Your earlier note said .forward( ) to the controller servlet failed. If you try sendRedirect( ) to the controller servlet and it happens to work, your decision is made. Or are you really asking how to change the . forward( ) to a sendRedirect( )? |---------+----------------------------> | | P. | | | Goovaerts@Clipper| | | .Be | | | Sent by: java400-| | | l-admin@midrange.| | | com | | | | | | | | | 08/07/02 02:47 AM| | | Please respond to| | | java400-l | | | | |---------+----------------------------> >----------------------------------------------------------------------- ------------------------------------------------| | | | To: java400-l@midrange.com | | cc: | | Subject: RE: HttpSession - problem | | | | | >----------------------------------------------------------------------- ------------------------------------------------| This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] Art, It seems to be a problem with (1) security (found out using sendRedirect()) (2) session-vars which doesn't exist when controller.servlet is called directly >>When it works with: Html ==> Loginid ==> jsp1 ==> controller.servlet >>==> jsp1 or jsp2 .... which api does jsp1 use to call >>controller.servlet? Also, did you try the earlier suggestion of using >>sendRedirect( ) api instead of .forward( ) to see if that helped at >>all? how do one decide which to choose: .forward() or sendRedirect() ? Patrick Goovaerts WebMaster Clipper Support nv TEL : 0032 (0)3 5453991 GSM: 0498 610 325 WEB: www.conti7.be _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
