Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Mix protocols transparently in Struts

Extend Struts to implement a mixed protocol solution for Web applications

By Steve Ditlinger, JavaWorld.com, 05/10/02

  • Print
  • Feedback

Page 4 of 6

Figure 2. UML diagram of the Struts 1.0 action-processing classes with added secure extensions



PageScheme custom tag

In my previous article, I discussed another piece of our mixed protocol solution, the sslext:pageScheme custom tag. You could use this tag to specify that a JSP should display with HTTPS by assigning a true value to the JSP's secure attribute. A false value would specify HTTP. We will implement this custom tag with its defining code and usage virtually unchanged from its description in the previous article. I include its source code and tag library descriptor, as well as the source code and tag library descriptors for all tags introduced in this article, in Resources.

SecureRequestUtils

The final part of our mixed protocol solution is the utility class SecureRequestUtils, which performs our algorithm's heavy lifting. From its introduction in the previous article, I've incorporated it here with few changes.

Solution complete?

If we stopped here, we would have finished implementing the mixed protocol solution as a Struts extension. Through careful specification of secure actions and JSPs, we could build Web applications on this framework that protect sensitive data during its transmission.

Some concerns can arise from less careful specification of secure Struts actions and JSPs. For instance, posting a large form from an HTTP-specified page to an HTTPS-specified Struts action could result in a query string from the posted request body parameters during the redirect that exceeds the browser or Web server's capacity. Also, although SSL protects the query string during the redirected transmission, users might feel uncomfortable with posted data appearing as part of the query string in the browser's location display.

We should make the solution foolproof. Fortunately, we can by again building upon the Struts infrastructure to extend some of Struts's custom tags.

Custom form tag

You can use the Struts custom tag html:form tag to render an HTML input form at runtime in the JSP. This tag's typical usage in its simplest form looks like this: 

<html:form action="/submitAction" >
        <!- The form's input elements specified here -->
</html:form>


At runtime, the tag would produce the following HTML form tag:

<form name="testForm" method="POST" action="/testssl/do/submitAction ">
        <!- The form's input elements specified here -->
</form>


The name testForm originates from the form bean's name we specified for the HTML form tag immediately above in our struts-config.xml file. The default method for html:form is POST, although you can specify GET submission methods for your forms using the method attribute. Finally, the action specified in the HTML form tag immediately above comes from the action we specified in the html:form tag. We just added the Web application's context root, testssl, and our SecureActionServlet's URL mapping, /do/*, to it.

Just as in SecureActionServlet's redirect logic, we can look at the secure property's value in the SecureActionMapping object for the action specified in the html:form tag to determine whether the form should be submitted via HTTP or HTTPS. We compare that submission specification with the protocol used to transmit the page containing the form. If the submission protocol fails to match the current page's protocol, you can specify the correct submission protocol in the resulting HTML definition for the form.

  • Print
  • Feedback

Resources