Using Java Server Pages | Java Security Solutions

The Java Server Pages (JSPs) are based on the Servlet specification. JSPs allow the development of Web pages that include dynamic content based on, for example, user identity. Once a JSP page is requested by the user , the server translates it into a Servlet, compiles it into a class, and executes it. Finally, the server services the request. The server may pre-compile the JSP code so that the JSP page does not have to go through all these steps every time it is requested. As long as the implementation is not changed, the request is serviced by just invoking the generated class directly. JSPs are just another way to write a Servlet and have the same advantages as a Servlet, such as scalability and security.

A JSP is composed of standard HTML code as well as special JSP elements that allow the server to include dynamic content. When a user requests a JSP, the server executes the JSP elements, merges the results with the HTML code, and then sends the complete content to the browser. Listing 27-2 illustrates how a JSP combines HTML and JSP tags to create a page with a dynamic project name in the header.

Listing 27-2: Simple JSP example

 <html> <head> <title>Project Detail</title> </head> <center> <h2> <font color=#DB1260>   <p>      <% String projname = request.getParameter("projname");         String projId = request.getParameter("projid");      %>     <strong>      <%= projname == null ? "": projname %>     </strong>     Project Details   </p> </font> </h2> </center> <body> <!-- do something useful  --> </body> </html>

Listing 27-2 demonstrates a couple of useful things. First, it illustrates combining HTML code with special JSP elements found within the " <% %> ". Second, it uses the HTTP request/response model to receive request parameters.

Request parameters can be sent in two ways: as part of the URI or as part of the request message body. In Listing 27-2, the request parameters are expected to be part of the URI. For example:

 http://localhost:7001/projinfo/projectDetail.jsp?projid=300- 01&projname=Hello

When the server executes the <% String projname = request.getParameter ("projname"); String projId = request.getParameter ("projid"); %> element, the projname string is set to " Hello " and the projId string is set to " 300-01 ".

When you code a URI link in an HTML page using an " <a> " element, the request generated uses the Get method. The Get method always passes parameters as part of the URI and is intended to retrieve a resource. No processing is expected to be done. Here is a way of generating the preceding URI:

 <a href="/projectDetail.jsp?projid=300-01&projname=Hello> The Hello  Project Link </a>

When it is embedded in a form, the code looks like the following:

 <form method="Get" action="/projectDetail.jsp"> Project Name: <input name="projname" type="text"> Project Id: <input name="projid" type="text"> <input type="SUBMIT"> </form>

Another way to transfer parameters is via the Post method. The Post method is intended to request a process from the server (such as updating a database). The Post method always sends the parameters as part of the body, and you can optionally also add parameters to the URI. In the code, however, the only thing that changes is the method attribute of the form element, as follows :

 <form method="Post" action="/projectDetail.jsp">

Tip	The POST method is favored over the GET method for delivering confidential request data, since data sent via Get appears in both client-side and server-side logs.

Different types of JSP elements, such as directives (like the <%@ include ...%> element), perform an action based on information obtained at the time the page is requested. Other elements include the action elements: There are standard action elements (like the <jsp:useBean> element), which are predefined, and custom action elements, which are defined by the developer. The final type of JSP elements are those used for scripting (such as the expression element <%! %> , and the expression <%= %> ).

Managing the state

Most applications need a way to keep track of the transaction state. For instance, a shopping cart application needs to remember what the user has selected during the various steps of the transaction. There are two basic solutions: Either the client keeps track of the state or the server does.

Either way, there is a need to let the other side know which state the transaction is in. For instance, if the client keeps the state, it needs to let the server know at each request what the state of the transaction is.

The browser can receive the state information via a cookie. A cookie is a name-value pair the server provides in the response header to the browser. The cookie can be embedded in the URI response where the server sends information to the browser as part of the URI and the browser sends information back as part of the request.

The state information may be embedded as fields in an HTML form. The server may send state information in hidden fields in the HTML form, and the browser may send back information as HTTP parameters.

However, passing information back and forth is inefficient. Therefore, a session is usually established, and a session ID is used to identify parts of the same transaction.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Beginning Cryptography with Java

Secure Programming Cookbook for C and C++: Recipes for Cryptography, Authentication, Input Validation & More

Network Security Architectures

Introducing Microsoft ASP.NET AJAX (Pro - Developer)

Persuasive Technology: Using Computers to Change What We Think and Do (Interactive Technologies)

Quantitative Methods in Project Management