Приглашаем посетить
Чехов (chehov-lit.ru)

Chapter 13.  User Authentication and Session Security

Previous
Table of Contents
Next

13. User Authentication and Session Security

WE ALL KNOW THAT HTTP IS THE Web protocol, the protocol by which browsers and Web servers communicate. You've also almost certainly heard that HTTP is a stateless protocol. The rumors are true: HTTP maintains no state from request to request. HTTP is a simple request/response protocol. The client browser makes a request, the Web server responds to it, and the exchange is over. This means that if I issue an HTTP GET to a Web server and then issue another HTTP GET immediately after that, the HTTP protocol has no way of associating those two events together.

Many people think that so-called persistent connections overcome this and allow state to be maintained. Not true. Although the connection remains established, the requests themselves are handled completely independently.

The lack of state in HTTP poses a number of problems:

  • Authentication Because the protocol does not associate requests, if you authorize a person's access in Request A, how do you determine whether a subsequent Request B is made by that person or someone else?

  • Persistence Most people use the Web to accomplish tasks. A task by its very nature requires something to change state (otherwise, you did nothing). How do you effect change, in particular multistep change, if you have no state?

An example of a typical Web application that encounters these issues is an online store. The application needs to authenticate the user so that it can know who the user is (since it has personal data such as the user's address and credit card info). It also needs to make certain datasuch as the contents of a shopping cartbe persistent across requests.

The solution to both these problems is to implement the necessary statefulness yourself. This is not as daunting a challenge as it may seem. Networking protocols often consist of stateful layers built on stateless layers and vice versa. For example, HTTP is an application-level protocol (that is, a protocol in which two applications, the browser and the Web server, talk) that is built on TCP.

TCP is a system-level protocol (meaning the endpoints are operating systems) that is stateful. When a TCP session is established between two machines, it is like a conversation. The communication goes back and forth until one party quits. TCP is built on top of IP, which is in turn a stateless protocol. TCP implements its state by passing sequence numbers in its packets. These sequence numbers (plus the network addresses of the endpoints) allow both sides to know if they have missed any parts of the conversation. They also provide a means of authentication, so that each side knows that it is still talking with the same individual. It turns out that if the sequence numbers are easy to guess, it is possible to hijack a TCP session by interjecting yourself into the conversation with the correct sequence numbers. This is a lesson you should keep in mind for later.


Previous
Table of Contents
Next