- •preface
- •acknowledgments
- •about this book
- •Who should read this book?
- •Roadmap
- •Code conventions
- •Code downloads
- •Author Online
- •About the title
- •About the cover illustration
- •Rethinking the web application
- •A new design for the Web
- •1.1 Why Ajax rich clients?
- •1.1.1 Comparing the user experiences
- •1.1.2 Network latency
- •1.1.3 Asynchronous interactions
- •1.1.4 Sovereign and transient usage patterns
- •1.1.5 Unlearning the Web
- •1.2 The four defining principles of Ajax
- •1.2.1 The browser hosts an application, not content
- •1.2.2 The server delivers data, not content
- •1.2.3 User interaction with the application can be fluid and continuous
- •1.2.4 This is real coding and requires discipline
- •1.3 Ajax rich clients in the real world
- •1.3.1 Surveying the field
- •1.3.2 Google Maps
- •1.4 Alternatives to Ajax
- •1.4.2 Java Web Start and related technologies
- •1.5 Summary
- •1.6 Resources
- •First steps with Ajax
- •2.1 The key elements of Ajax
- •2.2 Orchestrating the user experience with JavaScript
- •2.3 Defining look and feel using CSS
- •2.3.1 CSS selectors
- •2.3.2 CSS style properties
- •2.3.3 A simple CSS example
- •2.4 Organizing the view using the DOM
- •2.4.1 Working with the DOM using JavaScript
- •2.4.2 Finding a DOM node
- •2.4.3 Creating a DOM node
- •2.4.4 Adding styles to your document
- •2.4.5 A shortcut: Using the innerHTML property
- •2.5 Loading data asynchronously using XML technologies
- •2.5.1 IFrames
- •2.5.2 XmlDocument and XMLHttpRequest objects
- •2.5.3 Sending a request to the server
- •2.5.4 Using callback functions to monitor the request
- •2.5.5 The full lifecycle
- •2.6 What sets Ajax apart
- •2.7 Summary
- •2.8 Resources
- •Introducing order to Ajax
- •3.1 Order out of chaos
- •3.1.1 Patterns: creating a common vocabulary
- •3.1.2 Refactoring and Ajax
- •3.1.3 Keeping a sense of proportion
- •3.1.4 Refactoring in action
- •3.2 Some small refactoring case studies
- •3.2.2 Managing event handlers: Observer pattern
- •3.2.3 Reusing user action handlers: Command pattern
- •3.2.4 Keeping only one reference to a resource: Singleton pattern
- •3.3 Model-View-Controller
- •3.4 Web server MVC
- •3.4.1 The Ajax web server tier without patterns
- •3.4.2 Refactoring the domain model
- •3.4.3 Separating content from presentation
- •3.5 Third-party libraries and frameworks
- •3.5.2 Widgets and widget suites
- •3.5.3 Application frameworks
- •3.6 Summary
- •3.7 Resources
- •Core techniques
- •The page as an application
- •4.1 A different kind of MVC
- •4.1.1 Repeating the pattern at different scales
- •4.1.2 Applying MVC in the browser
- •4.2 The View in an Ajax application
- •4.2.1 Keeping the logic out of the View
- •4.2.2 Keeping the View out of the logic
- •4.3 The Controller in an Ajax application
- •4.3.1 Classic JavaScript event handlers
- •4.3.2 The W3C event model
- •4.3.3 Implementing a flexible event model in JavaScript
- •4.4 Models in an Ajax application
- •4.4.1 Using JavaScript to model the business domain
- •4.4.2 Interacting with the server
- •4.5 Generating the View from the Model
- •4.5.1 Reflecting on a JavaScript object
- •4.5.2 Dealing with arrays and objects
- •4.5.3 Adding a Controller
- •4.6 Summary
- •4.7 Resources
- •The role of the server
- •5.1 Working with the server side
- •5.2 Coding the server side
- •5.2.1 Popular implementation languages
- •5.3 The big picture: common server-side designs
- •5.3.1 Naive web server coding without a framework
- •5.3.2 Working with Model2 workflow frameworks
- •5.4 The details: exchanging data
- •5.4.2 Introducing the planet browser example
- •5.5 Writing to the server
- •5.5.1 Using HTML forms
- •5.5.2 Using the XMLHttpRequest object
- •5.5.3 Managing user updates effectively
- •5.6 Summary
- •5.7 Resources
- •Professional Ajax
- •The user experience
- •6.1 Getting it right: building a quality application
- •6.1.1 Responsiveness
- •6.1.2 Robustness
- •6.1.3 Consistency
- •6.1.4 Simplicity
- •6.1.5 Making it work
- •6.2 Keeping the user informed
- •6.2.1 Handling responses to our own requests
- •6.2.2 Handling updates from other users
- •6.3 Designing a notification system for Ajax
- •6.3.1 Modeling notifications
- •6.3.2 Defining user interface requirements
- •6.4 Implementing a notification framework
- •6.4.1 Rendering status bar icons
- •6.4.2 Rendering detailed notifications
- •6.4.3 Putting the pieces together
- •6.5 Using the framework with network requests
- •6.6 Indicating freshness of data
- •6.6.1 Defining a simple highlighting style
- •6.6.2 Highlighting with the Scriptaculous Effects library
- •6.7 Summary
- •6.8 Resources
- •Security and Ajax
- •7.1 JavaScript and browser security
- •7.1.1 Introducing the “server of origin” policy
- •7.1.2 Considerations for Ajax
- •7.1.3 Problems with subdomains
- •7.2 Communicating with remote services
- •7.2.1 Proxying remote services
- •7.2.2 Working with web services
- •7.3 Protecting confidential data
- •7.3.1 The man in the middle
- •7.3.2 Using secure HTTP
- •7.3.3 Encrypting data over plain HTTP using JavaScript
- •7.4 Policing access to Ajax data streams
- •7.4.1 Designing a secure web tier
- •7.4.2 Restricting access to web data
- •7.5 Summary
- •7.6 Resources
- •Performance
- •8.1 What is performance?
- •8.2 JavaScript execution speed
- •8.2.1 Timing your application the hard way
- •8.2.2 Using the Venkman profiler
- •8.2.3 Optimizing execution speed for Ajax
- •8.3 JavaScript memory footprint
- •8.3.1 Avoiding memory leaks
- •8.3.2 Special considerations for Ajax
- •8.4 Designing for performance
- •8.4.1 Measuring memory footprint
- •8.4.2 A simple example
- •8.5 Summary
- •8.6 Resources
- •Ajax by example
- •Dynamic double combo
- •9.1 A double-combo script
- •9.2 The client-side architecture
- •9.2.1 Designing the form
- •9.2.2 Designing the client/server interactions
- •9.3 Implementing the server: VB .NET
- •9.3.1 Defining the XML response format
- •9.4 Presenting the results
- •9.4.1 Navigating the XML document
- •9.4.2 Applying Cascading Style Sheets
- •9.5 Advanced issues
- •9.5.2 Moving from a double combo to a triple combo
- •9.6 Refactoring
- •9.6.1 New and improved net.ContentLoader
- •9.7 Summary
- •Type-ahead suggest
- •10.1 Examining type-ahead applications
- •10.1.2 Google Suggest
- •10.2.1 The server and the database
- •10.3 The client-side framework
- •10.3.1 The HTML
- •10.3.2 The JavaScript
- •10.3.3 Accessing the server
- •10.5 Refactoring
- •10.5.1 Day 1: developing the TextSuggest component game plan
- •10.5.3 Day 3: Ajax enabled
- •10.5.4 Day 4: handling events
- •10.5.6 Refactor debriefing
- •10.6 Summary
- •11.1 The evolving portal
- •11.1.1 The classic portal
- •11.1.2 The rich user interface portal
- •11.2 The Ajax portal architecture using Java
- •11.3 The Ajax login
- •11.3.1 The user table
- •11.4 Implementing DHTML windows
- •11.4.1 The portal windows database
- •11.4.3 Adding the JS external library
- •11.5 Adding Ajax autosave functionality
- •11.5.1 Adapting the library
- •11.5.2 Autosaving the information to the database
- •11.6 Refactoring
- •11.6.1 Defining the constructor
- •11.6.2 Adapting the AjaxWindows.js library
- •11.6.3 Specifying the portal commands
- •11.6.4 Performing the Ajax processing
- •11.6.5 Refactoring debrief
- •11.7 Summary
- •Live search using XSLT
- •12.1 Understanding the search techniques
- •12.1.1 Looking at the classic search
- •12.1.3 Examining a live search with Ajax and XSLT
- •12.1.4 Sending the results back to the client
- •12.2 The client-side code
- •12.2.1 Setting up the client
- •12.2.2 Initiating the process
- •12.3 The server-side code: PHP
- •12.3.1 Building the XML document
- •12.3.2 Building the XSLT document
- •12.4 Combining the XSLT and XML documents
- •12.4.1 Working with Microsoft Internet Explorer
- •12.4.2 Working with Mozilla
- •12.5 Completing the search
- •12.5.1 Applying a Cascading Style Sheet
- •12.5.2 Improving the search
- •12.5.3 Deciding to use XSLT
- •12.5.4 Overcoming the Ajax bookmark pitfall
- •12.6 Refactoring
- •12.6.1 An XSLTHelper
- •12.6.2 A live search component
- •12.6.3 Refactoring debriefing
- •12.7 Summary
- •Building stand-alone applications with Ajax
- •13.1 Reading information from the outside world
- •13.1.1 Discovering XML feeds
- •13.1.2 Examining the RSS structure
- •13.2 Creating the rich user interface
- •13.2.1 The process
- •13.2.3 Compliant CSS formatting
- •13.3 Loading the RSS feeds
- •13.3.1 Global scope
- •13.3.2 Ajax preloading functionality
- •13.4 Adding a rich transition effect
- •13.4.2 Implementing the fading transition
- •13.4.3 Integrating JavaScript timers
- •13.5 Additional functionality
- •13.5.1 Inserting additional feeds
- •13.5.2 Integrating the skipping and pausing functionality
- •13.6 Avoiding the project’s restrictions
- •13.6.1 Overcoming Mozilla’s security restriction
- •13.6.2 Changing the application scope
- •13.7 Refactoring
- •13.7.1 RSS reader Model
- •13.7.2 RSS reader view
- •13.7.3 RSS reader Controller
- •13.7.4 Refactoring debrief
- •13.8 Summary
- •The Ajax craftsperson’s toolkit
- •A.1 Working smarter with the right toolset
- •A.1.1 Acquiring tools that fit
- •A.1.2 Building your own tools
- •A.1.3 Maintaining your toolkit
- •A.2 Editors and IDEs
- •A.2.1 What to look for in a code editor
- •A.2.2 Current offerings
- •A.3 Debuggers
- •A.3.1 Why we use a debugger
- •A.3.2 JavaScript debuggers
- •A.3.3 HTTP debuggers
- •A.3.4 Building your own cross-browser output console
- •A.4 DOM inspectors
- •A.4.1 Using the Mozilla DOM Inspector
- •A.4.2 DOM inspectors for Internet Explorer
- •A.4.3 The Safari DOM Inspector for Mac OS X
- •A.5 Installing Firefox extensions
- •A.6 Resources
- •JavaScript for object-oriented programmers
- •B.1 JavaScript is not Java
- •B.2 Objects in JavaScript
- •B.2.1 Building ad hoc objects
- •B.2.2 Constructor functions, classes, and prototypes
- •B.2.3 Extending built-in classes
- •B.2.4 Inheritance of prototypes
- •B.2.5 Reflecting on JavaScript objects
- •B.2.6 Interfaces and duck typing
- •B.3 Methods and functions
- •B.3.1 Functions as first-class citizens
- •B.3.2 Attaching functions to objects
- •B.3.3 Borrowing functions from other objects
- •B.3.4 Ajax event handling and function contexts
- •B.3.5 Closures in JavaScript
- •B.4 Conclusions
- •B.5 Resources
- •Ajax frameworks and libraries
- •Accesskey Underlining Library
- •ActiveWidgets
- •Ajax JavaServer Faces Framework
- •Ajax JSP Tag Library
- •Ajax.NET
- •AjaxAC
- •AjaxAspects
- •AjaxCaller
- •AjaxFaces
- •BackBase
- •Behaviour
- •Bindows
- •BlueShoes
- •CakePHP
- •CL-Ajax
- •ComfortASP.NET
- •Coolest DHTML Calendar
- •Dojo
- •DWR (Direct Web Remoting)
- •Echo 2
- •FCKEditor
- •Flash JavaScript Integration Kit
- •Google AjaxSLT
- •Guise
- •HTMLHttpRequest
- •Interactive Website Framework
- •Jackbe
- •JPSpan
- •jsolait
- •JSON
- •JSRS (JavaScript Remote Scripting)
- •LibXMLHttpRequest
- •Mochikit
- •netWindows
- •Oddpost
- •OpenRico
- •Pragmatic Objects
- •Prototype
- •Qooxdoo
- •RSLite
- •Ruby on Rails
- •Sack
- •SAJAX
- •Sarissa
- •Scriptaculous
- •SWATO…
- •Tibet
- •TinyMCE
- •TrimPath Templates
- •Walter Zorn’s DHTML Libraries
- •WebORB for .NET
- •WebORB for Java
- •XAJAX
- •x-Desktop
- •XHConn
- •index
- •Symbols
- •Numerics
268CHAPTER 7
Security and Ajax
7.4Policing access to Ajax data streams
Let’s begin by reviewing the standard Ajax architecture, in order to identify the vulnerability that we’ll discuss in this section. The client, once it is running in the user’s browser, makes requests to the server using HTTP. These requests are serviced by web server processes (servlets, dynamic pages, or whatever) that return streams of data to the client, which it parses. Figure 7.8 summarizes the situation.
The web services or pages are accessible by external entities, without any additional work on our part—that’s just how the Internet works. It may be that we encourage outsiders to use our web services in this way, and we may even publish an API, as eBay, Amazon, and Google, among others, have done. Even in this case, though, we need to keep security in mind. There are two things we can do, which we discuss in the following two sections. First, we can design our web services interface, or API, in such a way that external entities cannot subvert the purpose of our web application—say, by ordering goods without paying for them. Second, we look at techniques to restrict access to the web services to particular parties.
7.4.1Designing a secure web tier
When we design a web application, we typically have an end-to-end workflow in mind. In a shopping site, for example, the users will browse the store, adding items to their baskets, and then proceed to checkout. The checkout process itself will
Web browser
Ajax client
Data stream
Server
Data stream |
|
The Internet |
Web services |
|
External entity
Figure 7.8
In an Ajax architecture, the server exposes web services to the Internet over a standard protocol, typically HTTP. The Ajax client fetches streams of data from the server. Because of the public nature of the web services, external entities may request the data directly, bypassing the client.
Policing access to Ajax data streams |
269 |
|
|
have a well-defined workflow, with choice of delivery address, shipping options, payment methods, and confirmation of order. As long as our application is calling the shots, we can trust that the workflow is being used correctly. If an external entity starts to call our web services directly, however, we may have a problem.
Screen scrapers and Ajax
A classic web application is vulnerable to “screen-scraping” programs that traverse these workflows automatically, crafting HTTP requests that resemble those generated by a user filling in a form. Screen-scrapers can deprive sites of advertising revenue and skew web statistics. More seriously, by automating what is intended to be an interaction between a human and the application, they can subvert the workflow of the application, calling server events out of order, or they can overload server processes by repetitive submission. From a security perspective, they are generally considered problematic.
The data in a classic web application’s pages is often buried within a heap of boilerplate HTML and decorative content. In a well-factored Ajax application, the web pages sent to the client are much simpler, well-structured data. Separation of concerns between presentation and logic is good design, but it also makes the job of a screen-scraper easier, because the data returned from the server is designed to be parsed rather than rendered in a browser. Screen-scraping programs tend to be fragile and are prone to break when the look and feel of the site changes. Visual makeovers of an Ajax client are less likely to alter the signatures of the underlying web services that the client application uses to communicate to the server. To protect the integrity of our application, we need to give some thought to these issues when designing the structure of the high-level API used to communicate between client and server. By API, we don’t mean HTTP or SOAP or XML, but the URLs of the dynamic pages and the parameters that they accept.
Example: online battleship game
To illustrate how the design of a web service API affects the security of the application, let’s look at a simplistic example. We’re developing an online version of the classic board game Battleship (see the Resources section), which will be played using an Ajax client that communicates to the server using web services. We want to ensure that the game is cheat-proof, even if a malicious player hacks the client, making it send data to the server out of turn.
The aim of the game is for each player to guess the position of the other’s boats. The game consists of two phases. First, the players each position their pieces on the board. Once this is done, they take turns at guessing particular
270CHAPTER 7
Security and Ajax
Client 1
Server
Client 2
Figure 7.9 Data models in an Ajax-based game of Battleship. Once the pieces are positioned, the server will maintain a map of both players’ pieces. The clients will initially model only their own pieces but build up a model of their opponent’s as the game progresses.
squares on the board, to see if they can sink the other player’s ships. The master copy of the board is stored on the server during a game, with each client also maintaining a model of its own half of the board and a blank copy of the other player’s board, which gradually gets filled in as their ships are discovered (figure 7.9).
Let’s look at the setup stage. First, the board is wiped clean. Then each piece is placed on the board, until all pieces are placed. There are two ways that we can design the service calls that the clients will make to the server during setup. The first is to use a fine-grained approach, with calls to clear the board and to add a given piece at a given position. During the setup phase, the server would be hit several times, once to clear the board and once to position each piece. Table 7.2 describes the fine-grained setup’s API.
|
|
Policing access to Ajax data streams |
271 |
|
Table 7.2 Fine-grained web API for Battleship game setup phase |
|
|||
|
||||
|
|
|
|
|
URL |
Arguments |
|
Return Data |
|
|
|
|
|
|
clearBoard.do |
userid |
|
Acknowledgment |
|
|
|
|
|
|
positionShip.do |
userid shiplength |
|
Acknowledgment or error |
|
|
coordinates (x,y) format |
|
|
|
|
orientation (N,S,E or W) |
|
|
|
|
|
|
|
|
The second design is a coarse-grained approach, in which a single service call clears the board and positions all pieces. Under this approach, the server is hit only once during setup. Table 7.3 describes this alternative API.
Table 7.3 Coarse-grained web API for Battleship game setup phase
URL |
Arguments |
Return Data |
|
|
|
setupBoard.do |
userid |
Acknowledgment or error |
|
coordinates array of (x,y,length, |
|
|
orientation) structs |
|
|
|
|
We already contrasted these two styles of service architecture when we discussed SOA in chapter 5. The single network call is more efficient and provides better decoupling between tiers, but it also helps us to secure our game.
Under the fine-grained approach, the client takes on the responsibility of checking that the correct number and type of pieces are placed, and the server model takes on the responsibility of verifying the correctness of the system at the end of the setup. Under the coarse-grained approach, this checking is also written into the document format of the service call.
Once setup is completed, an additional service call is defined to represent a turn of the game, in which one player tries to guess the position of another’s ship. By the nature of the game, this has to be a fine-grained service call representing a guess for a single square, as shown in table 7.4.
Table 7.4 Web API for Battleship game play phase (used for both fineand coarse-grained setup styles)
URL |
Arguments |
Return Type |
|
|
|
guessPosition.do |
userid |
“hit,” “miss,” or “not your turn” |
|
coordinates (x,y) |
plus update of other player’s last |
|
|
guess |
|
|
|