Project Information:template JSP Testing Tool Project - 50 Review - Self Evaluation - A
- 1 Summer of Code 2008 Report
- 2 Detailed Status Report
Summer of Code 2008 Report
|50% REVIEW PROCESS|
Project Deliveries & Objectives
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration the assumed ones, please exemplify writing down those of them that haven't been realised.
|While the tool is far from fully functional, all the stated "stage one" objectives have been achieved with the exception of JSP Tag Library 2.x support. See below for more details.|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration the assumed ones, please quantify in terms of percentage.
(1) Identify or Create Tag Library Parser: 75%
(2) Basic Test of Tags: 100%
(3) Design Report Format: 100%
3. What kind of help is required either from the Reviewers or from the OWASP Community?
|No help is required though any suggestions or improvement strategies for tag generation are welcome.|
Detailed Status Report
The following contains a detailed report on the status of the project. All current code has been added to a Subversion repository hosted by Google Code. The packaged source code along with required libraries is available at the project's Google Code home. Also available is a demo WAR file containing the generated report of the JSF Core tag
h:outputLink from the HTML Basic library. The demo was created by running the
main method from the
JspTester class which currently contains test code to invoke the tool on a subset.tld file which contains the single
h:outputLink tag. The resulting JSP files were then packaged along with the necessary XML configuration files and JAR libraries into the WAR file.
"Stage One" Objectives
The following For convenience, the development goals outlined in the original proposal are reproduced here:
- Identify or Create Tag Library Parser: The first step of this project is to determine a way to parse tag libraries and instantiate tag objects for testing. The Java EE API includes interfaces to parse and instantiate JSP tags so an initial investigation into existing implementations of tag parsers may yield an adequate source. However, since the interfaces are specified as protected and application server implementation specific, the interdependencies may require the creation of such a parser from scratch
- Basic Test of Tags: The second step is to use the parser and apply some basic initial test cases to test the protection of attributes from tainted input
- Design Report Format: The third step is to tabulate the results and create a simple format to convey those results.
Identify or Create Tag Library Parser
At the onset of the project, I was not aware of the various different versions of the JSP Tag Library specification. There are currently four versions of the specification: 1.1, 1.2, 2.0 and 2.1. Currently, the code parses all of the necessary code from a TLD File from a JSP Tag Library version 1.1 or 1.2 in order to generate tag test cases for all attributes. Some information such as listeners, validators, etc. are not parsed. The 2.x specifications are a superset of the elements used in the 1.2 specification and as a result, the parser can generally handle 2.x form TLDs. For example, the Sun provided JSF 1.2 TLDs have served as the de facto test case and the parser handles these TLDs gracefully. However, by ignoring the extra information provided in 2.x TLDs, the tool ignores information that can be used to improve successful generation of tags. For example, some of the information provided by a 2.x TLD includes type information on attributes and example tag usage. As a result, I have rated the percentage completion rate as 75%. Note that of all the work remaining, handling 2.x TLDs represents the easiest task and will likely take very little time to complete.
Basic Test of Tags
Tag generation is currently done by blind population of attributes using Jakarta ECS to generate the text itself. This at least allows for basic testing of most tags. More information about the basic testing is here. Again, while this strategy is relatively blind, the majority of the JSF HTML Basic components can be generated using this strategy and results in at least proof of concept. While there is much work to be done to improve the success rate in tag generation, this was expected and hence the "stage one" goal was extremely rudimentary. As a result, I have rated the percentage completion rate as 100%. Note that "stage two" objectives include work to improve tag generation.
Design Report Format
The initial design of the report is complete and the basic strategy is unlikely to change going forward. The report format is described in greater detail here. While there are possible aesthetic and usability improvements, functionally the report format is complete and as a result I have rated the percentage completion rate as 100%. Note that the stated "stage two" objectives include improvements to the report design.
The following is a list of known limitations as of the 50% Review.
Full TLD Support
As stated above, the tag library parser does not currently handle all information provided by TLDs.
Advanced Tag Generation
As stated above, the current tag generation strategy is blind and results in cases where tags are not generated correctly.
Out of Heap Space
As a side effect of blind tag generation, incorrect tag generation results in unhandled exceptions which propagate to the global error handler. Currently the errors are not handled gracefully which has resulted in memory exceptions related to the heap space. As a result, the provided demo only tests one tag from the JSF Core tag library. Even with this limited test, heap space exceptions tend to occur. Addressing this issue is two fold:
- Improve tag generation to reduce errors
- Improve error handling strategy to clean up errors so they do not exhaust heap space
In addition to addressing the known limitations cited above, the following additional objectives will be added to the "stage two" objectives
- Implement Deployment Method: As stated here, in order to view the report, a user must deploy the set of generated HTML/JSP files in a JSP container. This process is currently done manually. This new objective will be the creation of some mechanism to simplify the deployment of the report. One possible strategy is the creation of an Ant task to create a WAR file containing all necessary resources to deploy the report.
- Implement Invocation Method: The tool needs a way for users to invoke the operation on a given tag library. An initial strategy is providing a command line interface to interact with the tool.