One Cookie Only

Dissemino limits all visitors to a maximum of just one cookie because internally, cookies are mapped 1:1 to user sessions - which are instances of hdsInfo, a C++ class specifically designed to hold varied and complex session data. The rationale is that complex client states are better respesented by a purpose built class, than a series of application specific cookies. Such a series would consume bandwidth but more importantly, present significant difficulty in directing the application as to how they should be interpreted.

The recommendation is that web applications should not issue a cookie to visitors until they submit data to a form and so become users. Even then a cookie is only recommended where the form submission allows users to access resources or perform operations they could not access or perform otherwise. A registered user logging in will require a cookie but a sign up for a newsletter may not do. It is recognized however, that webmasters will be keen on techniques such as email verification. As these techniques require state to be maintained, it is anticipated most forms will trigger cookie issuance.

Cookie Format

Cookies as passed between server and client, are strings comprising a name-value pair, a URI (uniform resource indicator), and if the cookie is intended to persist, there will also be an expiry date. The name-value pair can be anything providing it amounts to a unique identifier. Dissemino always sets the name part equal to the cookieName parameter defined in the applicable sphere. It is only the value part that is unique and this is a 64-bit unsigned number (written as a 16-byte hexadecimal), based on the time and date of issue, client IP address and a sequence number that is incremented each time a client connects. This encoding allows cookies in the user session map to be stored as 64-bit numbers which are more compact and faster to compare than strings. The URI is always '/' so the browser will always return the cookie no matter what resource is requested. This is common practice anyway, but makes particular sense when there can only be one cookie and where the lookup cost is negligable.

Setting Cookies in the Application

It should be clear from the above that webmasters don't have much control over cookies. The only decision to be made is which parts of the web application need to be covered by the single cookie. If recommendations are followed, the cookie is to be issued upon form submission unless the process is completed within a single form submission and does not affect what the visitor is able to access. It is common for webmasters to direct all form handlers to issue the cookie.

There are two methods of directing cookie issuance. The most common method is to set the attribute 'ops' in the <xformHdl> form handler definition tag to "cookies". This will always result in a session (temporary) cookie being issued. The other method is to use Dissemino executive commands, namely EXEC_SESS_COOKIE and EXEC_PERM_COOKIE which are assumed to be self explanatory. Dissemino executive commands can be placed in form handlers but also in pages where they are invoked upon display. It should be noted however, that issuing cookies on page display is firmly against the recommendations as it will needlessly create a session. It is not the intention to encourage unnecessary tracking of users!

Webmasters will need to comply with EU regulations concerning cookie notices, where these apply. The cookie notice is an irritant worth avoiding where possible. It is not necessary to display the notice until a cookie is about to be issued so the obvious place to include it is in form. This is done in conjunction with an <xcond> tag to ensure the notice only appears when no cookie is in force. This way visitors who are only browsing site content, are not bombarded by it.

Cookie Use in Shopping Carts

Shopping carts are a special case because in the general they require a user session to hold the items, prior to the user filling out anything that would be considered a form.