Re: sslext can only get it to post
On Sun, 14 Sep 2003, Max Cooper wrote: Some design changes are needed to make the switch to the https port in what I consider to be an acceptable manner. One avenue to explore is using one particular capability of container managed security, and declare a security constraint requiring SSL on a particular request. Something like this: security-constraint web-resource-collection web-resource-nameCheckout Section/web-resource-name description The set of URL patterns for requests that must be submitted via SSL. In order to avoid sending confidential data unencrypted, these patterns MUST include the page that renders the form to be submitted that contains that confidential data. /description !-- URL pattern for the form containing the credit card number -- url-pattern/checkout_form.jsp/url-pattern !-- URL pattern for the buy it submit button -- url-pattern/buy.do/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint If you do this, the container will switch to HTTPS for you before the checkout form is rendered. Hence, the ultimate submit of that form will be done over SSL. It's up to the container to figure out what the correct SSL port number is (in Tomcat, you configure this with the redirectPort attribute on a Connector element; the default configuration for non-SSL on port 8080 redirects to SSL on port 8443). Note that, because there is no auth-constraint here, this particular security constraint does not require you to use container managed security for authentication -- it's only being used to do the redirect to SSL trick for you. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sslext can only get it to post
Yes, Tomcat's handling of the security-constraint is very complementary to the use of sslext. Unfortunately, unless this has changed recently, not all containers behave in this way. Weblogic, for instance, just creates a response that outputs a message to the browser stating that a particular URL is available only by HTTPS. (Maybe this has changed in 8.1, I'll check it out.) Tomcat definitely has the superior implementation on this issue. Steve - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Cc: Stephane Grenier [EMAIL PROTECTED] Sent: Monday, September 15, 2003 10:37 AM Subject: Re: sslext can only get it to post On Sun, 14 Sep 2003, Max Cooper wrote: Some design changes are needed to make the switch to the https port in what I consider to be an acceptable manner. One avenue to explore is using one particular capability of container managed security, and declare a security constraint requiring SSL on a particular request. Something like this: security-constraint web-resource-collection web-resource-nameCheckout Section/web-resource-name description The set of URL patterns for requests that must be submitted via SSL. In order to avoid sending confidential data unencrypted, these patterns MUST include the page that renders the form to be submitted that contains that confidential data. /description !-- URL pattern for the form containing the credit card number -- url-pattern/checkout_form.jsp/url-pattern !-- URL pattern for the buy it submit button -- url-pattern/buy.do/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint If you do this, the container will switch to HTTPS for you before the checkout form is rendered. Hence, the ultimate submit of that form will be done over SSL. It's up to the container to figure out what the correct SSL port number is (in Tomcat, you configure this with the redirectPort attribute on a Connector element; the default configuration for non-SSL on port 8080 redirects to SSL on port 8443). Note that, because there is no auth-constraint here, this particular security constraint does not require you to use container managed security for authentication -- it's only being used to do the redirect to SSL trick for you. Craig - 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: sslext can only get it to post
Hi Stephane, Here is how the system currently appears to work: 1. User is on shopping cart page, clicks checkout, the form is submitted unencrypted to the ShoppingCartAction (which is fine since it isn't supposed to be secure). 2. ShoppingCartAction does its magic (saves cart changes, for instance) and then forwards to the checkout JSP. 3. checkout.jsp has an sslext:pageScheme tag in it that says it is supposed to be secure. The current request was not secure, so the tag creates a redirect to the secure port with all the request parameters appended to the URL as a query string. By the time the app figures out that you want to go to the checkout, it is too late so sslext can't really help too much. The request has already been sent, and it wasn't secure. Some design changes are needed to make the switch to the https port in what I consider to be an acceptable manner. Here are some possible solutions: 1. I don't like this one, but you could have JavaScript submit the shopping cart form to ShoppingCartAction securely by changing the action to an absolute URL that starts with https when the user clicks the checkout button. There is an sslext:rewite tag that would be useful for this purpose. 2. If you have a checkout button other places on the site (not a form submit, but rather a simple link to some kind of CheckoutAction), you could have the ShoppingCartAction redirect to the CheckoutAction when it is done processing the changes in the cart. I am not sure if sslext will work its magic on forwards, which in this case is actually going to be a redirect by setting redirect=true on the forward. If sslext doesn't fix the redirect, I believe we can get Steve (sslext author) to make this change. It should work that way, IMO. Even if it doesn't switch on the redirect, it will switch with a second redirect so long as CheckoutAction is specified as a secure action. This would require the least amount of changes to the current actions if you already have a simple checkout link, and for that reason is my favorite solution if it would work for you. NOTE: This would be the app making the redirect to a different page, which is totally okay in my opinion -- my aversion to redirects is limited only to sslext doing the redirect itself to correct the port that the current request came in on. 3. If you don't have a simple checkout link, you could rework the app to make this work. This is a good idea anyway to encourage users to get to the checkout. The checkout action would need to access the contents of the cart from the session (since that information won't be coming in on the request), perhaps by accessing the shopping cart ActionForm from the session. Perhaps one of the property copying utilities from commons-beanutils would be useful for copying the cart contents to the checkout ActionForm. Once you get the simple checkout link working, just do a redirect to it as described in #3 above. 4. You could remove the sslext:pageScheme tag from checkout.jsp, which would avoid the redirect upon entering the page. The form on that page will submit the form securely since you have the sslext:form tag there and the action it submits to has been configured to be secure in struts-config.xml. However, this is one of those cases where users are likely to prefer that the form page itself is already secure, even though it isn't technically necessary. A note on the pageScheme tag: If all your pages are Struts actions and you use sslext:form and sslext:link to navigate to your secure actions, there is no need for the sslext:pageScheme tags. Configuring the actions in struts-config.xml is all that is needed (which I also prefer for its simplicity). The tag is convenient if you have directly-accessed JSPs and things that need to be secured and you dip the site one level deeper into the SSL bin, but otherwise they are of no value. -Max - Original Message - From: Stephane Grenier [EMAIL PROTECTED] To: Max Cooper [EMAIL PROTECTED]; Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 12, 2003 5:40 PM Subject: Re: sslext can only get it to post Hello Max. Thank you for the information. You cleared up some vagueness in my understanding. However let me expand more into the details. The thing is I'm not sure how to actually implement what you have just said, I actually think that is what I'm currently doing which it is obviously not... If you don't mind I'm sending you my relevant chunks of code. I would like to have the shopping cart page not secure, but once moving to the checkout section to start the ssl security. Struts-config.xml form-beans form-bean name=ShoppingCartForm type=com.rana.release.forms.ShoppingCartForm / form-bean name=CheckoutForm type=com.rana.release.forms.ssl.CheckoutForm / /form-beans action-mappings type=org.apache.struts.config.SecureActionConfig action path=/ShoppingCartAction type=com.rana.release.actions.ShoppingCartAction name=ShoppingCartForm
Re: sslext can only get it to post
Also, let me add, that I use the tag: sslext:pageScheme secure=true/ with secure being true or false depending on if I need encryption. And I've actually come to realize that the issue resides more in this tag than the other. If I set it to false the method is post. If I set it to true, it's not post. However I'm sure how else to set the security. If someone also knows of where one can find an example online with actions (rather than just jsp's) that would be greatly appreciated Thank you, Stephane - Original Message - From: Stephane Grenier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 12, 2003 2:06 PM Subject: sslext can only get it to post Hello all. I've added sslext to my struts application. However I can't seem to get it to post (the parameters are appended to the url). In the jsp, the form tag is: sslext:form action=ShoppingCartAction name=ShoppingCartForm type=com.rana.release.forms.ShoppingCartForm scope=request method=POST So as far as I can tell it should be a post. If I change the tabs from sslext to html then it puts the action in the url (http://localhost:8080/ShoppingCartAction.do). If I put the sslext it puts the jsp, the session id, and all the parameters. Thank you, Stephane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sslext can only get it to post
Stephane, The parameters are getting appended to the URL because sslext is doing a redirect. So the POST is probably working, but then sslext thinks the request should have arrived on the other port, and since you can't do a POST in a redirect, sslext appends the POSTed data to the URL as a query string and sends that as a redirect. Finally, the redirect comes in as a GET with the params on the query string. The solution is to configure the app so that the form will POST to the right port (i.e. have sslext write an absolute URL for you) and won't have to redirect. The real strength of sslext is that you can specify which actions are secure, and then as long as you use the sslext tags to navigate to that action (either with a link or a form tag), sslext will get you there WITHOUT HAVING TO DO A REDIRECT. That last part is important -- in my opinion, the app should be written such that sslext never has to do a redirect. It will do redirects for your convenience, but that is inefficient, turns POSTs into GETs, and has some security problems (there is no point in making a page secure if you are going to submit a form without SSL and then redirect it to the SSL port). An alternative approach is to dip your site one level deeper in SSL. For instance, if you want a form submittal to be secure, you can dip your site in the SSL a little deeper by specifying that BOTH the request that displays the form and the form submittal request itself are secure. Technically, you don't need to secure the request that displays the form, but by making it secure you avoid the redirect on the form submittal since you are already on the secure port. If you end up getting a redirect at form submittal, the effort to secure that form has been a folly since the form data has already passed over the network unencrypted twice and sticks in the browser's history after the redirect. I don't like this approach in most instances, and sslext gives you the power to do better without much effort. Here are some reasons I don't like it: 1) it is inefficient since it relies on using redirects to switch ports 2) it is inefficient since it requires sending more data over SSL than necessary (debatable) 3) it's too easy to inadvertently create security holes by forgetting to make the display form request secure 4) it is messy since you end up specifying which pages should be secure in several different ways (as opposed to ONLY doing it in struts-config.xml) Securing the display form request actually is appropriate in many instances, even though that request doesn't technically need to be encrypted. Users often want to get some feedback that they are working securely before filling out the form. But you can still achieve this goal without resorting to redirects. Of course doing it the right way requires that you use the sslext link and form tags all over the place (any time the request could change ports), which can be hard to remember sometimes if you are used to the Struts versions. The sslext versions aren't any harder to use (just a few additional optional attributes); it's just remembering to use them in the first place that can be problematic. For this reason, I would REALLY like to see sslext integrated into the Struts core. The only effect on users would be that they could now specify that an action (mapping) is to be secure, which is just how it should work. Holy crap, that turned into a bit of a rant. :-) Well, I hope you find the solution to your problem in there somewhere, and that perhaps some of this additional info is useful to you or other list members. -Max - Original Message - From: Stephane Grenier [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, September 12, 2003 11:06 AM Subject: sslext can only get it to post Hello all. I've added sslext to my struts application. However I can't seem to get it to post (the parameters are appended to the url). In the jsp, the form tag is: sslext:form action=ShoppingCartAction name=ShoppingCartForm type=com.rana.release.forms.ShoppingCartForm scope=request method=POST So as far as I can tell it should be a post. If I change the tabs from sslext to html then it puts the action in the url (http://localhost:8080/ShoppingCartAction.do). If I put the sslext it puts the jsp, the session id, and all the parameters. Thank you, Stephane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sslext can only get it to post
Hello Max. Thank you for the information. You cleared up some vagueness in my understanding. However let me expand more into the details. The thing is I'm not sure how to actually implement what you have just said, I actually think that is what I'm currently doing which it is obviously not... If you don't mind I'm sending you my relevant chunks of code. I would like to have the shopping cart page not secure, but once moving to the checkout section to start the ssl security. Struts-config.xml form-beans form-bean name=ShoppingCartForm type=com.rana.release.forms.ShoppingCartForm / form-bean name=CheckoutForm type=com.rana.release.forms.ssl.CheckoutForm / /form-beans action-mappings type=org.apache.struts.config.SecureActionConfig action path=/ShoppingCartAction type=com.rana.release.actions.ShoppingCartAction name=ShoppingCartForm scope=request set-property property=secure value=true/ forward name=update path=/shoppingCart.jsp/ forward name=checkout path=/purchase.jsp/ forward name=failure path=/contacts.jsp/ /action action path=/CheckoutAction type=com.rana.release.actions.ssl.CheckoutAction name=CheckoutForm scope=request set-property property=secure value=true/ forward name=success path=/contacts.jsp/ /action /action-mappings plug-in className=org.apache.struts.action.SecurePlugIn set-property property=httpPort value=8080/ set-property property=httpsPort value=8443/ set-property property=enable value=true/ /plug-in I've tried to play with the secure settings, could you confirm these ? I can't seem to make the app work correctly unless it's as the above specified. The action classes currently only contain : System.out.println(... whichAction); return (mapping.findForward(success)); and the formpages are very basic. The first page, shoppingCart.jsp: sslext:pageScheme secure=false / html:form action=ShoppingCartAction name=ShoppingCartForm type=com.rana.release.forms.ShoppingCartForm scope=request method=POST tdhtml:text property=quantity size=4//td td align=righthtml:image property=checkout src=images/buttons/Checkout.jpg border=0 //td /html:form I didn't use the sslext:form tag since it doesn't need to be encrypted. Also I know the action says for it to be secured, and this to me doesn't quite make sense, but it was the only way I could make it work. Lastly the checkout.jsp !--sslext:pageScheme secure=true /-- sslext:form action=CheckoutAction name=CheckoutForm type=com.rana.release.forms.ssl.CheckoutForm scope=request method=POST tdinput type=image name=checkout src=images/buttons/referralRewardProgram.jpg border=0/td /sslext:form I played with the sslext:pageScheme tag and I as I understand this is mostly a check to verify that the page is indeed secure, in case someone came in from just the address or what have you. And btw, the server.xml is : !-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- Connector className=org.apache.catalina.connector.http.HttpConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=false protocol=TLS/ Thank you for the help, Stephane - Original Message - From: Max Cooper [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Stephane Grenier [EMAIL PROTECTED] Sent: Friday, September 12, 2003 5:41 PM Subject: Re: sslext can only get it to post Stephane, The parameters are getting appended to the URL because sslext is doing a redirect. So the POST is probably working, but then sslext thinks the request should have arrived on the other port, and since you can't do a POST in a redirect, sslext appends the POSTed data to the URL as a query string and sends that as a redirect. Finally, the redirect comes in as a GET with the params on the query string. The solution is to configure the app so that the form will POST to the right port (i.e. have sslext write an absolute URL for you) and won't have to redirect. The real strength of sslext is that you can specify which actions are secure, and then as long as you use the sslext tags to navigate to that action (either with a link or a form tag), sslext will get you there WITHOUT HAVING TO DO A REDIRECT. That last part is important -- in my opinion, the app should be written such that sslext never has to do a redirect. It will do redirects for your convenience, but that is inefficient, turns POSTs into GETs, and has some security problems (there is no point in making a page secure if you are going to submit a form without SSL and then redirect it to the SSL port). An alternative approach is to dip your site one level deeper in SSL. For instance, if you want a form submittal to be secure, you can dip your site in the SSL a little deeper by specifying that BOTH the request that displays the form
