Cookies.Add Method

Creates a new cookie. You can then access this object through the cookie collection to set additional attributes.

Syntax

Response.Cookies.Add( cName )

Parameter

cName

Each cookie must have a unique name. This name can consist of the letters A to Z, numerals, and underscores. Umlauts are not valid. As per specification, cookies are case-sensitive. That is why the following code will create two cookies:

Response.Cookies.Add("id")

Response.Cookies.Add("ID")

It may not be wise to trust that all browsers will pay regard to these differences. For this reason, cookies with identical names but differing notation should be avoided altogether. If you enter an already existing name, the result will be that the existing cookie is overwritten.

Note

Response.Add() creates a cookie object that manages all attributes of a cookie. Immediately after its creation, a cookie has no value. For this reason you should first assign it a value:

Response.Cookies.Add("id")

Response.Cookies("Id").Value = m.lcID

The cookie object deposited in the collection has numerous attributes. These attributes are described below in detail. The cookie object has no methods.

The attribute Name holds the name used for the invocation of the method Add. You should not retrospectively change this value.

The actual cookie content is deposited in the attribute Value . At the next invocation the browser transmits the value contained in Value to Request.Cookies(). If no value is transmitted, the assumed value is an empty character string. Values can consist of letters, numerals und underscores. Umlauts and special characters are to be avoided, since depending on the browser and the OS, unexpected conversions can occur.

Cookies may have an automatic expiry date which is set in Expires. The cookie will not be saved permanently if no expiry date is transmitted. Most browsers will keep this value in the memory and discard it when the browser closes. Since this method does not allow permanent user tracking, many browsers permit the storage of these session cookies even if other cookies may not be saved.

If a date is transmitted, the cookie will not be transmitted to the server after that date. The local time of the client machine applies here. The date can be transmitted as a calendar date value or a date time value or else as a character string in the date format laid down by the Netscape specification.

The attribute Domain defines which server the cookie may be sent to. Before transmitting a cookie to a web page the browser checks if the web page is authorized to receive cookies. One of the criteria in this process is the server name. Cookies are only transmitted to the server that originally provided them. The name of the server is the essential criteria. The servers www.afpages.de and admin.afpages.de count as different servers.

The server name comparison starts from the right and goes up to the full length of the server name stored in the cookie. If the cookie was transmitted by a server named www.afpages.de, it will also be sent to web pages requested by the server secure.www.afpages.de, since in both cases the right-hand portion of the name is www.afpages.de. By contrast, a request to the server secure.afpages.de would not receive a cookie, since in this case ure.afpages.de would be compared to www.afpages.de.

The attribute Domain lets you determine the name of the server that will be saved with the cookie. By default this will be the full name of the server sending out the response. Occasionally you will want to send data to multiple servers or web applications. A frequent example of this would be the use of multiple web servers to process enquiries. Frequently, these are designated www1.afpages.de, www2.afpages.de, etc. To transmit the cookies to all these servers you will have to explicitly set the domain:

Response.Cookies("Id").Domain = ".afpages.de"

The domain specification must always be preceded by a dot. Interpretation by the browser may prove to be a pitfall. The original Netscape documentation required a minimum of two dots with an explicit domain specification if the top level domain corresponded to one of the following values: COM, EDU, NET, ORG, GOV, MIL or INT.

Since country-specific domains like US for the U.S.A. or DE for Germany were not included in that rule, such domains have to be preceded by a minimum of three dots. A browser complying with the Netscape specifications would therefore reject ".afpages.de" but accept ".afpages.com". Only statements like ".shop.prolib.de" would be accepted; in this case, a cookie would be expanded to encompass the server secure.shop.prolib.de.

Since this proved to be impracticable, the standard RFC 2109 now merely requires that every specification should start with a dot and contain one embedded dot flanked to the left and to the right by letters. In the case of the specification ".afpages.de" this would be the dot between "afpages" and "de".

An additional criterion is the path which you can set through the attribute Path. If no path is entered, all cookies are transmitted as a matter of principle every time a server calls a page. If you enter a path you can confine this transmission to a subdirectory. If e.g. there is an application in http:/server.de/sales, you can prevent the transmission of cookies to other applications in the same domain by entering "/sales" in the parameter Path.

A path is always inclusive of all subordinate paths. Entering the path "/" will also transmit cookies to all pages of a domain. Please note that paths are separated by "/" rather than by the backslash "\" commonly used in Windows.

The attribute Secure is a logical value with the default setting .F. If set to .T., the client will send the cookie only via a secure connection (HTTPS protocol). This setting is essential for the prevention of so-called Cookie Replay attacks. These are attacks where an intruder monitors the network traffic between client and server.

This can easily be done through spy-ware that has been installed in the machine. But even inside a network all data sent over a network section can be read by all machines. Network cards normally process only data packages that are directed to the cards themselves or to everybody. They can, however, be configured to process the entire network traffic. To prevent this all computers have to be connected to a switch rather than a hub. You should consider this aspect when you select your Internet provider to connect your own machine there.

Thus, if you use a cookie for user identification and an intruder can intercept it, he can send that cookie with his own request and thus pretend to the server that he is actually the other user. If HTTPS (SSL encryption) is used, no third party can eavesdrop on the network traffic. That is why cookies sent via HTTP are inherently secure. To completely prevent all eventualities of attack you also have to make sure that neither the client nor the server send out a cookie through an unsecured connection where it could be intercepted. On the client side this can be ensured through the attribute Secure:

Response.Cookies("Id").Secure = .T.