Cutting Edge Research in Engineering of Web Applications
Cutting Edge Research in Engineering of Web Applications Part 2 What is Different about Engineering Web Apps? Jeff Offutt Professor of Software Engineering George Mason University http: //www. cs. gmu. edu/~offutt/ offutt@gmu. edu
Outline A. Who am I ? B. Who are you ? Part 1 (13: 00 -15: 00) Part 2 (19: 00 -21: 00) 1. Web Apps Overview 4. Control Flow & State Handling is Different 2. How the Interweb Works 3. Web Software (Servlets) 5. State Handling in JSP Part 3 (Friday 13: 00 -15: 00) 6. Web Software Security 7. Modeling Web Apps 8. Testing Web Apps 9. Engineering Process July 2013 © J Offutt 2
Tracking State Information • The initial versions of the web suffered from a lack of state: HTML Form Data Server Info HTML Page • If you wanted multiple screens, there was no way for data to be accumulated or stored Form 1 D 1 Form 2 D 1 Server July 2013 D 1+D 2 Form 4 D 1+D 2+D 3 Server © J Offutt D 1+D 2+D 3+D 4 Server 3
Session Tracking • Web applications must maintain user states • This is called session tracking July 2013 © J Offutt 4
Session Tracking (2) Session. A : series of related interactions between a client and a web server (similar to a use case) • Session tracking refers to keeping data between multiple HTTP requests • This problem is essential to maintaining state, which we understand quite well in the context of traditional procedural programming and object-oriented programming • The Web brings in unique constraints HTTP is connectionless July 2013 Distributed © J Offutt 5
New Control Flow and State Handling To support session handling (and other issues) J 2 EE introduced new language mechanisms 1. New control flow mechanisms 2. New state management 3. New variable scopes July 2013 © J Offutt . . 6
Traditional Control Flow • Procedural languages – Method / function calls – Decisions – if, while, for, repeat-until, switch, … – Static includes – other code pulled in before compiling • OO languages – Dynamic binding via polymorphism • Client / Server – Message passing July 2013 © J Offutt 7
Web App Control Flow (1) Traditional Control Flow Mechanisms 1. Same as traditional – Software on server and client 2. Synchronous message passing – Client to server, HTTP – Also server to other servers 3. Event handling – On the client July 2013 © J Offutt 8
Web App Control Flow (2) 4. 5. 6. 7. 8. 9. July 2013 New Control Flow Mechanisms Asynchronous message passing – Client to server, Ajax Forward – Transfers control from one server component to another, no return Redirect – Ask client to send request elsewhere URL rewriting by users Dynamic include – Control passes to another component, then returns, no parameters Dynamic binding – Reflection allows new components to be added and used dynamically © J Offutt 9
Ramifications of New Control Flow • The traditional control flow graph does not model essential parts of web app execution ! • UML diagrams do not model many of these • Most developers learn the syntax, but not the concepts behind these new control connections Lots of poorly designed software … and lots of poorly understood software faults ! July 2013 © J Offutt 10
New Control Flow and State Handling To support session handling (and other issues) J 2 EE introduced new language mechanisms 1. New control flow mechanisms 2. New state management 3. New variable scopes July 2013 © J Offutt . . 11
Handling State in Procedural Languages • The C programming language has simple ways to handle state Global variable char name [25]; main () { int x, y, z; Local variables . : • We added several layers of scope in OO languages July 2013 © J Offutt 12
State in Object-Oriented Languages • In addition to local and global variables, OO languages have other scopes – Nonlocals : package, protected, default, … • Data sharing in OO languages – Two components can share data if they are in the same scope – Two components can share data by passing parameters • OO languages also are based on the concept of objects, which are instances of classes – Classes define types, which are global – Objects can be defined at multiple scopes July 2013 © J Offutt 13
Handling State in Java Class 1 Package public members protected members Class 3 default private members inheritance Class 2 Class 5 July 2013 Class 4 © J Offutt 14
State on the Web • These schemes have two simple, subtle, assumptions : 1. The software components share physical memory 2. The program runs to completion with active memory • But these assumptions are violated in web applications ! 1. Distributed software components 2. Connectionless nature of HTTP • To keep state in web applications, we need different ways to store and access variables and objects Public access and parameter passing are not enough in Web applications! July 2013 © J Offutt 15
State and Session Tracking • Session tracking refers to passing data from one HTTP request to another • A web application is comprised of several software components • The characteristics of a Web app means that the components do not communicate directly – – Independent processes (threads) Connectionless protocol Client-server or N-tier architecture Execution flow always goes through a client How can these independent components share data? July 2013 © J Offutt 16
Session Tracking Methods 1. Include data as extra parameters (URL rewriting) 2. Hidden form fields 3. Cookies 4. Servlet API session tracking tools All four methods work by exchanging a token between the client and server Client C July 2013 Request with a Token Response with a Token © J Offutt Server S 17
(1) URL Rewriting • Forms usually add parameters URL ? P 1=v 1 & P 2=v 2 & P 3=v 3 & … • You can add values in the URL as a parameter : HREF = ". /servlet/X ? Sneaky. Param=42"> or : User=george"> • This is used as a key to find the saved information about the user george – – – July 2013 Messy and clumsy Long URLs Information on URL is public All HTML pages must be created dynamically Often limited in size © J Offutt 18
(2) Hidden Form Fields • Flows of control go through the client • Data that must be passed from one software component to another can be stored in hidden form fields in the HTML • Generate HTML pages with forms that store “hidden” information : <INPUT type=“hidden” name=“User” value=“george”> • Several problems : – Insecure – users can see the data – Unreliable – users can change the data – Undependable – users can use the back button, direct URL entry, and URL rewriting to skip some hidden form fields • Still useful in limited situations July 2013 © J Offutt 19
(3) Cookies • Cookies are small files or text strings stored on the client’s computer • Created by the web browser • Arbitrary strings, but sometimes var=value pairs or XML • Java coding : Cookie c = new Cookie (“user”, “george”); c. set. Max. Age (5*24*60*60); // expires in 5 days, in seconds response. add. Cookie (c); // sends cookie to client July 2013 © J Offutt 20
(3) Cookies – cont. • • Cookies are very useful and simple Not visible as part of the HTML content Convenient way to solve a real problem But cookies are scary ! – It’s as if I stored my files at your house – Cookies go way beyond session tracking – Cookies allow behavior tracking July 2013 © J Offutt 21
(4) Servlet Sessions The servlet API uses cookies to provide a simple, safe, flexible method for session tracking • • Cookies are handled automatically Http. Session stores data in the current active object • Data disappears when the object is destroyed • Object is destroyed after the session ends, usually 30 minutes after the last request July 2013 © J Offutt 22
Sessions—Big Picture Time Web Server Client 1 HTTP Request Time HTTP Request HTTP Response Session ID = 0347 HTTP Response Session ID = 4403 Server returns a new HTTP Request unique session ID Session ID = 0347 when the request has HTTP Response none HTTP Request Session ID = 4403 HTTP Response HTTP Request Session ID = 0347 HTTP Request Session ID = 4403 HTTP Response July 2013 Client 2 HTTP Response © J Offutt 23
Sessions—Big Picture Time Web Server Client 1 HTTP Request HTTP Response Session ID = 4403 HTTP Request Session ID = 0347 Session ID = 4403 HTTP Response Client stores the ID and sends it to the server in Request HTTP Session ID = 0347 subsequent requests July 2013 Time HTTP Request HTTP Response Session ID = 0347 Server recognizes all HTTP Response the requests as being from the same client. This defines a session Client 2 HTTP Response HTTP Request Session ID = 4403 Server recognizes these requests as being from a HTTP Response different client. © J Offutt 24
Servlet API Session Methods • The servlet API methods are not synchronized • Multiple servlets can access the same session object at the same time • If this can happen, the program must synchronize the code that modifies the shared session attributes July 2013 © J Offutt 25
Session Definition A session is defined by • The web server – Servlet container – Servlet context • The client – IP address – Browser • Session objects are kept on the server • Each session object uses different parts of memory (instances of data values) on the server July 2013 © J Offutt 26
Example Consider a small Web app with 2 servlets and 3 JSPs Servlet S 1 Servlet S 2 Client JSP 1 JSP 2 JSP 3 How can the servlets and JSPs share data? July 2013 © J Offutt 27
New Control Flow and State Handling To support session handling (and other issues) J 2 EE introduced new language mechanisms 1. New control flow mechanisms 2. New state management 3. New variable scopes July 2013 © J Offutt . . 28
Sharing Data : Session Object • One program component can store a value in the session object • Another component can retrieve, use, and modify the value • Depends on the servlet container : – Software components are threads, not processes – Servlet container stays resident and can keep shared memory July 2013 © J Offutt 29
Session Data Example Software components share “container” access data Servlet Container Servlet S 1 Session object Servlet S 2 Client JSP 1 JSP 2 JSP 3 July 2013 © J Offutt 30
Login Example 1. User request Form Entry 2. Check is. Logged. In 3. if is. Logged. In false Login 4. Set is. Logged. In true and set user. ID 7. if is. Logged. In false 5. User request July 2013 is. Logged. In: T/F user. ID: string 6. Check is. Logged. In View Data © J Offutt 31
Session and Context Scopes • The session object is available to software components in the same request and session – They have access to the session ID – This is called session scope • Sometimes we need a wider scope – – Chat rooms : Allow multiple users to interact Group collaboration : Online meeting Online bidding Reservation systems • J 2 EE also defines a context scope This allows us to share data among multiple users July 2013 © J Offutt 32
Context Scope Container Engine session Servlet S 2 object 1 Servlet S 1 session object 2 JSP 3 JSP 1 context JSP 2 object Session 1 July 2013 Context (application) © J Offutt Session 2 33
Session and Context Scope Examples Compare attribute. Servlet and servlet. Context examples http: //cs. gmu. edu: 8080/offutt/servlet/attribute. Servlet http: //cs. gmu. edu: 8080/offutt/servlet. Context Try them in different browsers Compare the differences July 2013 © J Offutt 34
Control Flow & State Summary • Managing state is fundamental to any program • Managing state is the most unique aspect of designing and programming web applications • Software vendors are creating new frameworks all the time – Most of them introduce additional state handling techniques • Many professional developers make fundamental mistakes with managing state State management is the most common source of software faults in web applications July 2013 © J Offutt 35
Outline A. Who am I ? B. Who are you ? Part 1 (13: 00 -15: 00) Part 2 (19: 00 -21: 00) 1. Web Apps Overview 4. Control Flow & State Handling is Different 2. How the Interweb Works 3. Web Software (Servlets) 5. State Handling in JSP Part 3 (Friday 13: 00 -15: 00) 6. Web Software Security 7. Modeling Web Apps 8. Testing Web Apps 9. Engineering Process July 2013 © J Offutt 36
Java Server Pages • A JSP is a scripted page that mixes programming statements into HTML • JSP scriptlets: – Have a Java-like syntax – Can use external objects and call methods – Can process form data • JSPs are translated to Java servlets, then compiled • The help separate presentation from data July 2013 © J Offutt 37
JSP Scope & State Management • JSPs formalize this with four separate scopes 1. 2. 3. 4. Page : Within the same program component (web page) Request : Within the same request Session : Within all requests from the same session Application : Within all sessions for one servlet context • Each can be accessed by different sets of program components • Some exist for different periods of time http: //cs. gmu. edu: 8080/offutt/jsp/642/counter. Scope. jsp July 2013 © J Offutt 38
Sharing Data with Scope page forward st e u requ est request Client 1 page forward session request page Client 2 July 2013 application © J Offutt 39
Web Apps State Summary • Programmers often get state management wrong – They learned “how” without learning “why” (the theory) – They don’t understand the differences in the various scopes – They forget to consider which scope to use as part of design • State management is very different from traditional programming • These scopes are quite powerful • New frameworks beyond J 2 EE often add different scopes or different semantics on the same scopes http: //cs. gmu. edu/~offutt/classes/642/examples/jsp/ July 2013 © J Offutt 40
- Slides: 40