Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


How to Get Around the Eolas Patent—Automatically : Page 2

Unless it's overturned, the Eolas ruling means tens of thousands of Web pages that use embedded plugins are infringing on the patent. Based on a procedure recommended by Microsoft, this filter will automatically update your HTML so you'll be in the free and clear.




Application Security Testing: An Integral Part of DevOps

Breaking it Down
The MicrosoftEolasFilter requires only five short source files. These files are the Web server filter (written in Java), the XSLT script, two JavaScript files that the transformed OBJECT block will rely upon, and the snippet to add to your Java server's web.xml configuration.

The Filter
The first step is to create the filter. The filter source (see Listing 1) contains only three methods of note, which are required to implement the javax.servlet.Filter interface. The interface requires the implementation of the following three methods:

public void init(FilterConfig config) public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) public void destroy()

The init method provides an opportunity for the filter to set up. It receives XML-based configuration information drawn from the server web.xml file.

public void init(FilterConfig config) throws ServletException { xslPath = config.getServletContext().getRealPath(config.getInitParameter("xslPath")); }

This method is where the filter will get the name of the XSLT script needed to drive the page transformation. This information will be saved to a string in the class and used later in the doFilter method.

The next method, doFilter, is the heart of the filter itself. This is the method that the filtering mechanism in the server calls to start the filter's functionality.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // open the XSLT script source Source xsl = new StreamSource(new File(xslPath)); // establish writer wrappers PrintWriter out = response.getWriter(); CharResponseWrapper wrapper = new CharResponseWrapper((HttpServletResponse) response); // be friendly with the filter chain chain.doFilter(request, wrapper); // open an input stream on the page Source xml = new StreamSource(new StringReader(wrapper.toString())); try { // startup the transformation engine TransformerFactory factory = TransformerFactory.newInstance(); Transformer transformer = factory.newTransformer(xsl); // establish an output for the transformation CharArrayWriter caw = new CharArrayWriter(); StreamResult result = new StreamResult(caw); // transform the source transformer.transform(xml, result); // write the transformed output response.setContentLength(caw.toString().length()); out.write(caw.toString()); } catch(Exception e) { e.printStackTrace(out); } }

This bit of code is lengthy so in attempt to make things easier to follow, the description that follows will move along from source comment to source comment.

The first thing to do is to open the XLST script, whose name was drawn from the configuration file in the init method, as a transformation source. With the input established, you have to prepare the output stream back to the server. This is done with simple print and character wrapper classes. If you are even slightly versed in servlet construction this is pretty bland stuff.

An important next step is to invoke the filter chain. This is standard filter processing and it better allows the Java Server to make determinations about the execution order of the filters. In most cases the MicrosoftEolasFilter should be the last filter called, this is not a strict requirement but it is preferable. If your server configuration has different filters installed you may have to do some testing by shuffling the order that they appear in the web.xml configuration file. An example of when it would not be good for the MicrosoftEolasFilter to be the last filter would be if your server used a page compression filter. It would be difficult to perform an XSL transformation on compressed text.

Once back from executing the other filters in the chain, create an XML source reader on the page. Then start up the transformation engine and create an output source for the result. Then, because of compact design, you can call the transformation with one easy method call, perform the transform, and pass the XML source reader opened on the page, dumping the results to the Writer you created just before the transformation.

When you have the results back, you can write them to the servlet's output buffers. Any exceptions thrown during the transformation are caught and, for the sake of debugging, are displayed to the servlet's output buffer. In production, it would be a wise idea to instead return the unaltered response in case of any problems, as users wouldn't be too happy to receive a stack trace.

While establishing the Writer wrappers on the servlet's response instances you might notice a class called CharResponseWrapper. This is a simple inner class to the MicrosoftEolasFilter that merely implements the HttpServletResponseWrapper interface around a CharArrayWriter.

The last required method for the Filter interface's implementation is the destroy method. Because there is no specific clean up necessary with this filter it is an empty method.

The compiled source will result in two files, the filter itself and its inner class. Package these up into a JAR and deposit them into the server's library directory and configured path.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date