After a brief discussion of Web database applications, the authors offer a rapid tour of PHP essentials, including loops, expressions, functions and common mistakes. Next comes a quick-start guide to MySQL, focusing mainly on the SQL language itself. The following chapters tackle connecting to MySQL and other databases, implementing user-driven queries and enabling writing as well as reading data. There is a useful chapter on data validation, both on the client and the server and excellent coverage of another crucial subject: security and authentication. This looks at the fundamentals of HTTP authentication and examines security features in both Apache and PHP, identifying weaknesses and explaining pros and cons. The closing chapters form a detailed case study, an online wine store, with complete code available for download. It embraces user management, a shopping cart, searching, ordering and delivery, covering many key topics in the process. At the back of the book are appendices on a range of issues, including installation, Web protocols, database modelling and session management.
Web Database Applications is tightly-focused, packing in lots of solid technical information without wasting words. It does not pretend to cover all the potential uses of PHP, and the screen shots will not win prizes for design, but it's a great handbook for building robust, secure database applications with these popular technologies. --Tim Anderson
From the Publisher
About the Author
Since the mid 1990s David Lane has worked as a software engineer and IT manager with the Multimedia Database Systems group at RMIT University in Melbourne, Australia. In that group he has helped to develop and commercialize the Structured Information Manager, a large-scale SGML/XML document repository and a high performance Web server. David has also worked with Australia's largest telecommunications company, Telstra, in areas as diverse as Satellite Communications, Human Factors Research, and Electronic Document Interchange (EDI). David has a Bachelor's degree in Applied Science (majoring in mathematics and computer science) from Swinburne University.
Excerpt. © Reprinted by permission. All rights reserved.
A fundamental characteristic of the Web is the stateless interaction between browsers and web servers. As discussed in Chapter 1, HTTP is a stateless protocol. Each HTTP request a browser sends to a web server is independent of any other request. The stateless nature of HTTP allows users to browse the Web by following hypertext links and visiting pages in any order. HTTP also allows applications to distribute or even replicate content across multiple servers to balance the load generated by a high number of requests. These features are possible because of the stateless nature of HTTP.
This stateless nature suits applications that allow users to browse or search collections of documents. However, applications that require complex user interaction can't be implemented as a series of unrelated, stateless web pages. An often-cited example is a shopping cart in which items are added to the cart while searching or browsing a catalog. The state of the shopping cart--the selected items--needs to be stored somewhere. When the user requests the order page, the items for that user need to be displayed.
Stateful web database applications can be built using sessions, and session management is the topic of this chapter. In this chapter we:
Discuss how sessions are managed in the stateless environment of the Web and introduce the three characteristics of server-side session management
Introduce cookies for storing state
Show how to use and configure the PHP session management library
Use PHP session management to improve the client entry <form> in the winestore case study
Provide a brief list of reasons for using, or avoiding, session management over the Web
Building Applications That Keep State
Applications sometimes need to use the result of one request when processing another. For example, a request that adds an item to a shopping cart needs to be remembered when the request is made to create the order. In other words, the state of the application needs to be stored between HTTP requests. There are two ways to achieve this: variables that hold the state can be stored in the browser and included with each request or variables can be stored on the server.
Managing State in the Client Tier
Data sent with the GET or POST methods can include the application state with each HTTP request. An illustration of this approach can be seen in the previous and next browsing features developed in Chapter 5. In this example, there are two pieces, or states, that need to be considered when a page is browsed: the query parameters the user provided and which page should be displayed.
The solution developed in Chapter 5 encodes the query and an offset as an embedded link.
This solution allows navigation through large search result sets. Similar solutions are used in the URLs generated to jump between the results pages of web search engines such as Google or Altavista. Cookies can be used for the same purpose.
Encoding the variables that hold state with each HTTP request increases the amount of data that has to be transmitted over the Web, and when data is encoded using the GET method, applications can generate long URLs. While HTTP doesn't restrict the length of URLs, some older browsers and proxy servers do enforce limits.
When state variables are encoded as part of the URL, or even when they are included as cookies, it is possible for the user to change the values that are sent with the request.
Changing the offset in a results page is harmless, but changing the item price of a bottle of wine is more serious. As discussed in Chapters 6 and 7, an application can't rely on data that is sent from the browser.