HTTP is the main protocol that powers the web. It is ideal for live interaction between user and server. It is a relatively simple interchange of text messages that allows one computer to request information from another. Besides asking for the file, it supplies information about itself, such as its capability to accept various file types. The server responds with it own messages. In a simple and successful interchange, the server also downloads the file that was requested .
A fundamental characteristic of HTTP interchange is that it is stateless. Each transaction is independent. Each request or response is a brand-new interaction between strangers. There is no recognition or memory of previous interactions a week ago or ten seconds ago. Any history ”either a long- term account or the record of a simple session (the interactions of a single visit) ” must be maintained by the server application. It requires cooperation from the client that must introduce itself to the server again with every mouse click.
The strategies for recognition typically include an ID code generated by the server and embedding into the downloaded page, along with the code that causes the client to include this label with each subsequent request. This code might be a simple session ID or a long-term identity, such as a customer relationship. Cookies help maintain both short-term identity and informal long-term history. Password identification and similar tactics are generally part of long-term authentication.
Most servers follow NCSA web standards in limiting access to files. Webmasters can apply protection where they desire it. Only users who can supply a valid name and password are allowed access to protected portions of the file structure. These limits are set on a per-directory basis and apply to all the files in the directory and all its subdirectories.
When a page is requested from a protected directory, the user is presented with a dialogue that requests the user's name and password (Figure 7.1). The name and password are tested against a file (. htaccess ) that is maintained by the webmaster in the directory being protected. Authorizations can also be set on a per-method basis and can limit only GET or only POST methods. (GET and POST methods are discussed a bit later in this chapter.)
Figure 7.1. Authorization Request
Flash developers must bear in mind the authorization limits on their web. The requests made by the Flash application are subject to the same limits as manual web browsing. If the server with which you are communicating is protected, your Flash application should be served from the same directory. Both the .swf file and the HTML file in which it is embedded must be stored in this directory. The user is asked for a name and password when the HTML file is first displayed. In Figure 7.2, . htaccess protects proprietary and all her daughter directories. Flash will be able to read prop_catalog.xml only if it has been loaded from the /proprietary/index.html page by a user who supplied a valid password.
Figure 7.2. Controlling Web Authorization
Authentication and authorization are often steps in establishing sensitive communications (such as a credit card purchase). They are typically transacted using HTTPS, which is simply normal HTTP transmitted over an encrypted socket. This socket is an isolated layer that supports the HTTP layer but does not interact with it. Thus, to the programmer developing an interactive experience, the addition of SSL (secure sockets layer) is essentially transparent.