Web-tier Design Issues & Refactorings

Web-tier Design Issues & Refactorings

Web-tier Design Considerations • Session Management • Client Access Control • Duplicate Form Submission • Validation

Session Management • Session State on Client • Easy to implement • Avoids state replication across servers • HTTP Cookies, and HTML Hidden Fields • Security Concerns • Session State on Server • Servlet Session Object • Server Farm? • Server Affinity or Use Business Tier Solution

Client Access Control • Role Based Access • Front Controller • Centralizes access control • Embedded Access Control • Good for portions of pages • Runtime system configuration

Embedded Access Control <%@ taglib uri=“…../qos.tld” prefix=“qos” %> <qos:authorizePage role=“admin” /> <html> … </html Or <%@ taglib uri=“…../qos.tld” prefix=“qos” %> <html> Some unprotected stuff <qos:authorizePortion role=“admin”> Some protected stuff </qos:authorizePortion> Some unprotected stuff </html>

Duplicate Form Submission • Protect against hitting back button and resubmitting form information • Synchronizer (or Déjà vu) Token • Set token in user’s session and include with each form submission • Update token in user’s session when submission takes place • Can also use a synchronizer token to direct flow through site. • When a page is accessed, update/check synchronizer token

Validation • Client validation vs Server validation • Client • Simple validation using Javascript • Don’t rely on because client side languages can be disabled • Server • Validate as you extract information from the form • Error Handling • Error Vector Bean • As errors happen, put them in vector • Forward right back to current page • Page always displays errors • Errors are best noted near the field where the error occurred.

Validation validate • Consider validation based on abstract types • Separate the validation of the model data from the controller logic • Validation is more generic or controller Model

Web-tier Bad Practices • Duplicate Control Code in Multiple Views • Exposing Presentation-tier data structures to business tier • HttpServletRequest etc. • Allowing duplicate form submission • Exposing sensitive resources to direct client access • Creating Fat Controllers

Refactorings

JSPView 1 Client Front Controller JSPView 2 JSPView 3 JSPView 4 Helper class Helper class Java Bean Introduce a Front Controller • Problem: Control logic is scattered throughout the application • Communicate with views using a session bean on the server

Servlet forwarding public void doGet(…)… { String op = request.getParameter(“operation”); if (operation == null) gotoPage(“URL1”, request, response); else if (operation.equals(“op1”)) gotoPage(“URL2”,request, response); } private void gotoPage(Sting URL, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(URL); dispatcher.forward(request, response); }

JSPView 1 Client Front Controller JSPView 2 JSPView 3 JSPView 4 Helper class Helper class Java Bean Introduce a Synchronizer Token • Problem: Clients make duplicate Requests or out-of-order requests • Solution: Shared token stored in the session token

Synchronizer Token • Generate token upon sending form • Include in the form • Compare token when data is returned • Change token when data is submitted

Hide Presentation Specific Detail from the Business Tier • Rather than passing presentation specific objects to business tier, place data in a more generic structure Web Business Web Business HttpServletRequest HttpServletRequest HttpServletRequest UserInfo

Other Refactorings • Remove Conversions from view • Use helper classes • Hide Resources from clients • Use Front controller • Use container controls

Handling Forgotten Passwords • User Information should contain a secure email address. • Email password to address • This assumes that if user has lost control of email, they have more serious problems than a forgotten password. • Java Mail API

Web-tier Design Issues & Refactorings