Yes, in this case, by specifying redirect, you are also clearing out the posted parameters. This is OK because you don't need them anymore after the login action. However since you proceed directly to another action from the login action, there is no point where our extension intervenes to send you to the non-secure action without our own second redirect. (However, you have inspired us to perhaps add this feature.) When our code does later perform the second redirection, there are no post parameters to stick in the query string
Internally this posted-parameters-to-query-string process has prompted much debate. While we all agree that something like this is needed, we would like to improve this feature so that we never add parameters to the query string. We just haven't figured out how to do it yet. Until we add the Greg-inspired feature and/or find an alternate general solution to the query string, you will need to continue to specify redirect="true" in situations like this to avoid displaying posted data in the location field. Thanks, Steve -----Original Message----- From: Greg Hess [mailto:[EMAIL PROTECTED]] Sent: Monday, February 18, 2002 7:01 AM To: Struts Users Mailing List Subject: RE: Bug with SSL Max, Steve: Thank you, my parameters are no longer visible. From what I can see(please correct me if I am wrong) after the original post using SSL, the SSL process listening to port(443) decrypts the encrypted post parameters and places them in the request for the Servlet to process. In the scenario that I am switching between HTTPS and HTTP in the same request I will always have to redirect instead of forward to avoid the parameters being visible. Greg -----Original Message----- From: Ditlinger, Steve [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 16, 2002 1:14 AM To: 'Max Cooper'; Struts Users Mailing List Subject: RE: Bug with SSL Max, Greg: I successfully tried your given solution. The posted parameters are no longer seen in the location field. Steve -----Original Message----- From: Max Cooper [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 4:16 PM To: Struts Users Mailing List Subject: Re: Bug with SSL Greg, Please try setting the redirect attribute of your success action forward to true in the struts-config.xml file, like so: <forward name="success" path="/mainPage.do" redirect="true" /> I'm going to try out this scenario and report back with any additional tips that I can think of. -Max ----- Original Message ----- From: "Greg Hess" <[EMAIL PROTECTED]> To: "Struts Mail List" <[EMAIL PROTECTED]> Sent: Friday, February 15, 2002 11:34 AM Subject: Bug with SSL > Hi All, > > I am using the classes provide by http://struts.ditlinger.com/ to allow for > switching between Http and Https calls in my Struts application. I have > installed SSL and is working fine under a test certificate. I am using the > the extended <ssl:form> > , <ssl:linktags> and the secure property in my Action definitions. I would > like my main logonForm to be submitted using SSL and after the username and > password are received on the server using SSL to switch back to http. What > happens is that the secure data posted by logon.jsp is visible in the > location > http://localhost/emailssl-struts/mainPage.do?password=hess&submit=Submit&use > rname=ghess. I have tried having the LogonAction setRedirect(true) on the > ActionForward returned but with no success. Unfortunately this is making my > secure data visible, how can I fix this bug. > > <!-- Direct main page requests --> > <action > path="/mainPage" > type="org.apache.struts.actions.ForwardAction" > parameter="/maintemplate.jsp"> > <set-property property="secure" value="false"/> > </action> > > <!-- Process a user logon --> > <action > path="/logon" > type="com.wrappedapps.email.LogonAction" > name="logonForm" > scope="request" > validate="true" > input="/logon.jsp"> > <set-property property="secure" value="true"/> > <forward name="success" path="/mainPage.do" /> > </action> > > Thanks, > Greg > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
