Restricting Access Based on Password


At this point, you've made use of the response object in filters, but filters can also work with the request object, as WebLogger does. Using the request object lets you handle data on its way to the filtered web resource. For instance, one of the most popular uses of filters is to restrict access to web resources based on password; take a look at Figure 6.4, where an HTML page, login.html, is asking the user for his password.

Figure 6.4. Restricting access-based passwords with a filter.


If the user enters the correct password, he's OK'd by the filter, which passes control on to a JSP named loggedin.jsp, as you see in Figure 6.5.

Figure 6.5. Gaining access with a password.


On the other hand, if the user enters the wrong password, the filter denies access and displays the error page you see in Figure 6.6.

Figure 6.6. Denying access for an incorrect password.


The interesting thing here is that you're reading data from HTML controlsa password control in this casein the filter. The data in the password control isn't even used in the target JSP. In the first HTML page the user sees, login.html, the password control is simply named password:

 <HTML>     <HEAD>         <TITLE>Log in</TITLE>     </HEAD>     <BODY>         <H1>Log in</H1>         <FORM ACTION="loggedin.jsp" METHOD="POST">             Enter your password:             <INPUT TYPE="PASSWORD" NAME="password">             <INPUT TYPE="SUBMIT" VALUE="Submit">         </FORM>     </BODY> <HTML> 

When the user clicks the Submit button, the request object, including the entered password text, is sent to the JSP page given by the HTML form's action, loggedin.jsp. But the password isn't used by loggedin.jsp; instead, it's used by the filter, Authenticate.java. To recover that password, the filter uses the request object's getParameter method:

 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class Authenticate implements Filter {   public void doFilter(ServletRequest request, ServletResponse response,     FilterChain chain)     throws IOException, ServletException   {     String password = ((HttpServletRequest) request).getParameter("password");         .         .         .   }   public void destroy()   {   }   public void init(FilterConfig filterConfig)   {   } } 

If the entered password matches the actual password (say, "opensesame"), the filter will pass control on to the filtered resource, loggedin.jsp:

 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class Authenticate implements Filter {   public void doFilter(ServletRequest request, ServletResponse response,     FilterChain chain)     throws IOException, ServletException   {     String password = ((HttpServletRequest) request).getParameter("password");     if(password.equals("opensesame")) {         chain.doFilter(request, response);         .         .         .     }   }   public void destroy()   {   }   public void init(FilterConfig filterConfig)   {   } } 

Here's the JSP page, loggedin.jsp, that the user sees if he has entered the correct password:

 <HTML>     <HEAD>         <TITLE>User authentication</TITLE>     </HEAD>     <BODY>         <H1>User authentication</H1>         Congratulations, you're in!         <BR>     </BODY> </HTML> 

On the other hand, if the password didn't match, the filter sends back an error page and denies access to the filtered resource:

 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class Authenticate implements Filter {   public void doFilter(ServletRequest request, ServletResponse response,     FilterChain chain)     throws IOException, ServletException   {     String password = ((HttpServletRequest) request).getParameter("password");     if(password.equals("opensesame")) {         chain.doFilter(request, response);     } else {         response.setContentType("text/html");         PrintWriter out = response.getWriter();         out.println("<HTML>");         out.println("<HEAD>");         out.println("<TITLE>");         out.println("Incorrect Password");         out.println("</TITLE>");         out.println("</HEAD>");         out.println("<BODY>");         out.println("<H1>Incorrect Password</H1>");         out.println("Sorry, that password was incorrect.");         out.println("</BODY>");         out.println("</HTML>");     }   }     .     .     . } 

You can add this filter to web.xml, as before:

 <?xml version="1.0" encoding="ISO-8859-1"?>         .         .         . <web-app>   <filter>     <filter-name>Simple Filter</filter-name>     <filter-class>Simple</filter-class>   </filter>   <filter>     <filter-name>Authentication Filter</filter-name>     <filter-class>Authenticate</filter-class>   </filter>         .         .         .   <filter-mapping>     <filter-name>Authentication Filter</filter-name>     <url-pattern>/loggedin.jsp</url-pattern>   </filter-mapping>   <filter-mapping>     <filter-name>Restricting Filter</filter-name>     <url-pattern>/game.jsp</url-pattern>   </filter-mapping> </web-app> 

REAL-WORLD SCENARIO: Passwords and Security

Filters are often used to enforce password access to web resources, but using a filter this way isn't the most secure way of restricting access. The problem is that sending data from password controls around the Internet means that your unencrypted text may go through as many as 20 servers to get where it's going.

Not exactly the most secure system out there, especially if you use the GET method in your HTML forms, which means that your password data will be appended to the URL, something like this: http://localhost:8080/logger/loggedin.jsp?password=opensesame.

Talk about security leaks.

If security is a serious concern, developers usually go for some other technique, such as using server-based passwords. These passwords are set on the server, and when the user logs in, the browser displays a login dialog box. How do you set up that kind of security, called HTTP authentication? See the next topic.


To take a look at this filter in action, start Tomcat after installing the filter and navigate to http://localhost:8080/logger/login.html.



    Java After Hours(c) 10 Projects You'll Never Do at Work
    Java After Hours: 10 Projects Youll Never Do at Work
    ISBN: 0672327473
    EAN: 2147483647
    Year: 2006
    Pages: 128

    Similar book on Amazon

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net