    |  Chapter 8: Processing Data With Scripts The Art of Scintography Edition 3.0 © 2008 Aurora Isaac www.scintography.com | ||||
 8.1 Client Server Conversations | |||||
So far we have demonstrated techniques for bringing information, in the form of web pages, to the client.
Now we will consider ways that information is collected from the client.
The use of web pages to collect data usually involves a conversation between the client and the server.
The same protocol that brings web pages to your browser can also send data back to the server.
 Forms are used to input data on web pages. Forms can accept a variety of viewer inputs, including text, selections or options, and files. Access to client information is limited due to security precautions, but some data is available, and can be collected without viewer input. The first chance you have to examine input data is with a client script. Client side scripts, such as VBScript and JavaScript, are used for prescreening data. For example, essential fields should not be left blank. Your client script can check this before the data is sent to the server. Client scripts can also make the data collection process user friendly by offering interactive guidance. Form data is transmitted to the server with the common gateway interface ( CGI ) protocol. When your data reaches the server, it is received by a server script, addressed by its URL in the same way an HTML file is addressed by its URL. A variety of script languages can be used to create .cgi scripts. Although PERL has been the traditional favorite for server scripts, any language that can be compiled or interpreted on the server can be used, including the C languages, UNIX Shell, Visual Basic, etc. Languages such as Hypertext Preprocessor (PHP) and Active Server Pages (ASP) are integrated into HTML source files. The .php and .asp files are essentially HTML files with special tags containing scripts that are interpreted and processed at the server before the source is sent to the client. Scripts, like any other program on a computer, may interact with other files and applications on the server, including database applications. Regardless of what else it does, your server script must create a page to return to the client. At the very least, this will be an acknowledgement of the data received. This new page may very well include more forms, continuing the conversation between the client and the server. | |||||
| 8.2 Using Forms | |||||
|
A typical client/server conversation begins with a URL request sent by the client.
This may be a link clicked by the viewer or typed into the address line,
or a page loaded into a frame within the page.
When the URL request is received by the server, the requested HTML page is sent back to the client and loaded into the browser.
The viewer may then fill in the form fields and submit the form to the server.
When the form is submitted, another URL request, along with the CGI data, is sent to the server.
The server script addressed by the URL receives and processes the CGI data, then returns another page to the client.
 In the following example a form is contained in an inline frame. When this page was loaded, a URL request was sent to the server. The response from the server displays the form seen below. If you submit this form, another URL request, along with your inputs, will be sent to the server. The server script will then create a response that will replace the form in the inline frame. Note – this example reads and acknowledges form input, but does not store any data.
In this simple example, the server script responds the same way every time you submit a comment. No information is transmitted to identify continuity with previous comments. Although this is a conversation of sorts, neither the server nor the client scripts retain any memory of this conversation from one hit to the next. HTTP is a stateless protocol, without memory. | ||||
| 8.3 Cookies | |||||
|
Cookies were invented to provide client/server conversations the means to save state.
A cookie is a string of read/write information stored on the client computer.
Cookies may be accessed through your browser, but are insulated from the rest of your computer to maintain security.
They provide a way to preserve small bits of information pertinent to the operation of your site, personalized to the client.
This information can be stored, then accessed during a subsequent visit by your script.
 Although cookies are stored on the client, they are each associated with the page of origin, and the domain containing that page. Each time a URL request to that site is made by the client, the cookie is also sent, allowing server scripts to access and update cookie data. Although cookies solve some of the problems of client/server conversations, they have two major faults. Cookies are limited to small amounts of data that may not be sufficient to store the needed information. And, cookies are transmitted with the URL request across the network – not necessaruly a secure process. Also, cookies may not be available on all clients and can easily be eliminated by the client operator. | ||||
| 8.4 Sessions | |||||
|
Sessions were invented to provide servers the means to maintain state for the duration of a client/server conversation.
A session can be started when a server script is accessed.
When the script opens a session, a session ID is sent, either in a form or a cookie, to the client and back again on the next contact.
The server can reconnect its remembered session data with the returned session ID.
Unfortunately (for the server) the conversation is controlled by the client. A viewer may interrupt or abandon the session at any time. Because of this, sessions time out so the server is not clogged by abandoned session data. The next time the viewer accesses the site, a new session is started, with no memory of the previous session. Server scripts often use sessions in combination with authentication and permanent data storage to identify viewers on repeat visits. Viewers are authenticated by username and password, stored on the server, at the beginning of each new session. Using server storage also allows preservation of more extensive data, such as might be needed for a blog.  Now sites have the means to identify viewers and store their data. The types of transactions taking place on the Internet often involve the exchange of sensitive personal data such as bank account numbers, social security numbers, and the names and passwords that are meant to protect them. The final challenge in maintaining the integrity of a client/server conversation is security. | |||||
| 8.5 Secure Transmission | |||||
Encrypted transmission was invented to provide privacy for client/server conversations.
Assuming the site server is in the control of honest, reliable personel who vigilantly maintain its security,
and the client computer is not bugged with spyware, data still has to get from one to the other and back.
Data transmitted through the Internet resides, momentarily, on a number of servers along the way.
On any one of these servers, data may be compromised.
Secure transmission solves this problem.
 Normal transmission is done with HyperText Transfer Protocol (HTTP). Secure transmission is done with Secure HyperText Transfer Protocol (HTTPS) using Secure Socket Layers (SSL) to encrypt and decrypt the client/server conversation. To provide SSL capability, a site must have an SSL Certificate. When an HTTPS URL request is received by a certified server, a conversation begins between the client and the server before any URL transmissions are made. In this initial conversation the certificate is verified by the client and private session keys are made. Once the keys are established, the rest of the conversation is encrypted. Anyone intercepting data during the rest of the conversation will not have a key, and will not be able to compromise the transmission. Before you enter your personal data into a form, you should always ask these questions. Can I rely on this server? Two pieces of information in the URL should be checked. Are they using secure transmission (HTTPS)? If the S is missing, don't send your data. Does the domain name belong to this company? Scams may look authentic, but the domain name must be real. Is the certificate valid? If the certificate has expired, you might reconsider. Was it issued by a reliable SSL Certificate Vendor? Anyone can issue a certificate. One of the main security features of SSL is knowing who you are doing business with. Reliable vendors make sure the business is real before issuing a certificate. Is secure transmission established? Check to make sure your status line is visibie. In the status line of newer browsers, a lock will appear when secure transmission has been established. This means the neccessary conversation between the browser and the server has taken place, and your data will be encrypted before it is sent to the server. Before you put up a site that collects sensitive information, be sure your viewers will get the answers they deserve when they ask these same questions. | |||||
| 8.6 References | |||||
|
1
The Common Gateway Interface http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
2
COMODO
3
:WhichSSL: What is SSL?
4
:WhichSSL: Vendor Market Share
5
Cookiecentral.com
6
The Javascript Source
7
JavaScript: The Definitive Guide
8
: Saving State with Cookies
9
Microsoft Developers Network Library
10
: All About Scripting, Nancy Winnick Cluts
11
: An ASP You Can Grasp: The ABCs of Active Server Pages, Nancy Winnick Cluts
12
: Cookies
13
: DHTML Properties
14
O'Reilly perl.com: The Source for PERL
15
OurShop.com: How does ssl work?
16
PERL Mongers: The PERL Advocacy People
17
PHP
18
: Session Handling Functions
19
SSL: How can I tell if a web page is secure?
20
VeriSign
21
:SSL: How it Works
22
Webopedia
23
:SSL: Your Key to E-commerce Security | |||||
| All Contents © 2008 Aurora Isaac. All Rights Reserved. Legal Notices. | |||||
| |||||