Composr Tutorial: Introduction to Cookies and sessions (and JavaScript)

This is a tutorial that will explain the concept of cookies and sessions, as well as briefly explain how they relate to JavaScript in Composr.

This tutorial is mostly for interest, it is not required understanding for normal Composr use.

Cookies

A cookie is a named piece of data, created and used by a certain website for a certain viewing user, and sent from the user's web browser to the web server each time a page is viewed.

Originally there was no way to identify a user on the web that was viewing a website with a user that had previously visited, unless they had an account on the website and logged in each time. It was possible to identify a user within a visit, without them being logged-in, by storing additional information in URLs: however this is unwieldy.

Cookies were designed to resolve this problem, and another one:

1. it would allow server-side web applications to identify a specific user by the computer they accessed with
2. it would allow client-side web applications to have a memory, which was otherwise impossible

Login cookies

It is necessary that cookies contents are not predictable, or people could simply recreate a cookie file on their own computer with the identity of a website administrator, for example. Composr stores (if the user requests it) login cookies, that contain a username and a 'hashed' password. A hashed password is a password that can not be reasonably converted to the plain-text one; this provides some level of protection if the hashed password ever gets found out: the hacker can still impersonate a user on the website if they have the user's hash, but they cannot do so on other sites that the user has the same password on. Because no one can predict another user's password hash, they cannot fake their login.

Composr supports integration of login cookies with third party forum systems that run using a Composr forum driver. This support is unofficial, as it is inherently problematic for many reasons. For more information, please see the Nuances of forum integration tutorial.

Sessions

A session identifies a user, even if they are not a member. It is a unique number attached to a user and stored in a 'session cookie' or their URLs. A session cookie is a special kind of cookie that is automatically deleted when a user closes their web browser.

Session cookies are used as the primary means of Composr user identification. Once a user is established to be a guest, or they have logged in (or their login cookies have logged them in), a session will be created/resumed that uniquely identifies them; for members, the session is tied to their member account.

Sessions have the following advantages over conventional cookies:

• they allow remembering of guests
• they can be used to force explicit login for a member (see the Security tutorial for more information on this)
• they can be used even when cookies are disabled

Note that IP addresses could never be used instead of sessions because they are often shared between multiple users, and because a single user's dynamic IP address may often change. Composr has an added layer of security, in that it only allows a session cookie to work if it was created for a similar IP address: this reduces the security risk of 'session stealing' if a hacker somehow managed to find another user's session (which should not be possible in itself).

JavaScript

JavaScript is built into web browsers directly. It is used to provide an interactive element to the user's experience in their web browser.

Composr detects JavaScript by making the web browser write a cookie using JavaScript – if such a cookie exists, Composr knows that JavaScript is enabled. Likewise, if the cookie does not get set, Composr knows JavaScript is probably not enabled.

While this is indirect, and requires one page view before detection is accurate, it is the best way to detect JavaScript because web browsers do not announce its presence to web servers directly.

If Composr says JavaScript is not enabled it can mean three things:

1. JavaScript truly isn't enabled
2. Session Cookies are disabled
3. The Composr cookie settings chosen at installation are incorrect

Number 2 is the most likely cause, and this can be adjusted in the "Privacy" options of Microsoft Internet Explorer: it is the simplistic "High privacy" slider that causes many users to disable cookies, when in fact cookies are just one of many ways that people may be tracked (hence it is false piece of mind, at the expense of functionality). A good way to determine whether session cookies are disabled is by going back to your website after closing the browser window: if the URLs in Composr have a keep_session bit in them then it means that session cookies are disabled. Microsoft Edge does not have this problem because you would have to explicitly disable cookies in this browser (the Internet Explorer security level feature is not in Microsoft Edge).

If the problem is number 3, then you can adjust your cookie setting by opening up http://yourbaseurl/config_editor.php – if you wipe out the "cookie_domain" setting so it is blank, and set "cookie_path" to "/" then cookies should always save correctly.

If the problem is number 1, then you can adjust the browser settings to reenable JavaScript. In Microsoft Edge / Internet Explorer, the setting you need is under the "Security" options tab. While it is true that most security risks involve JavaScript, disabling JavaScript is like not leaving your house in case you are mugged – you also limit your positive experiences, and lock yourselves out of normal functionality that is a part of most websites.

Privacy

Cookies can only be read by the site that created them, or a site 'underneath' the site that created them. This prevents other websites from stealing cookies.

When cookies were fairly new, there was a lot of controversy about their ability to track users browsing 'all around the web'. This is not really the case, due to sites only being able to read their own cookies; however, for affiliated companies, such as advertising companies, it is true that cookies could be placed in banners such that any site showing a banner could aid the banner company in tracking every website the banner viewer visited on their network.

Therefore as more paranoid users may feel the need to disable their cookies, Composr does not require them: session details may be relayed by URL in Composr. The obvious disadvantage is that automatic login is not possible in this situation, and there is an additional disadvantage that JavaScript will be thought to be disabled, as Composr needs to use cookies to detect it. The first problem may be ameliorated by the web browser 'auto-fill' feature, which can be used to automatically remember how forms, such as login forms, were filled in.

The developers recommend that users do have cookies enabled, but that they possibly disable 'third party cookies' if they are concerned about privacy so that advertisers can not track the advertising sites that they view.

EU legislation

20 things you didn't know about cookies (for programmers)

1. All cookies have an expiry time. A cookie that has expired in the past will be deleted once the web browser is closed. Cookies can also be deleted explicitly.
2. It is this expiry behaviour that leads to 'session cookies'. Session cookies have no actual definition beyond that they are defined to expire in the past from the very time that they are created. The emergent behaviour is that they act as temporary cookies, existent only for a browser session.
3. Session cookie XSS prevention security is lost if web browser tabs are used: the cookies don't expire because the browser is never closed.
4. Cookie expiry time is measured in GMT UNIX timestamp seconds, hence client/server time is theoretically the same – but care is still needed as computer clocks may be fast/slow
5. A third-party cookie is a cookie that is set onto a domain name that the main page document cannot read. This is possible only because a document may reference images on other servers, and these images may themselves set cookies (any URL can generate cookies). Some browser privacy settings disable these.
6. While cookies are sometimes disabled by people for privacy concerns, session cookies are usually allowed as an exception – so it isn't the end of the world if session cookies are required – but it's better to be able to store session IDs in the URL. Some popular websites do require cookies to be enabled though (Tesco.com, New York Times, …).
7. Full cookie data is sent with all web requests that the cookies are scoped under, even image requests – so it is inefficient to store a lot of cookies.
8. Cookies must be set against a domain name. This is either done by putting .domain as the cookie domain, or by leaving the domain blank when setting the cookie; the domain should never be defined as domain as it will not work properly.
9. Cookies work with an elaborate but confusing precedence system. Only cookies underneath a matched domain/path combination will be sent to a server URL (for privacy reasons), and they will be given precedence based on 'most specific gets priority'. To change a cookie the server must set it against the domain/path combination it was created with. The variables a cookie was defined under are not available server-side, which means that anyone modifying the cookie must know these in advance, or guess wildly.
10. There is a legitimate privacy concern with cookies when ads are concerned. Banner rotations run from centralised sites, and hence have the ability to effectively track users from this centralised site but with regard any site that they visit that uses the rotation. Nevertheless, such tracking could happen regardless of cookies, via server logging and cross-server messaging – so blaming cookies is simplistic.
11. Microsoft made a great extension to Netscape's original cookie spec, allowing 'HTTP only' cookies (cookies that JavaScript cannot read). Use of this prevents XSS many vulnerabilities.
12. At the protocol level, cookies are sent to the server in a single Cookie HTTP header, but set from the server using individual Set-Cookie headers.
13. Cookies just store names and values, and never any data that a web server or normal JavaScript would not have been able to discern – because it is the web server or browser that sets the cookie.
14. JavaScript provides its cookie support by a virtual variable, document.cookie. The variable can be set and read, but the process is not actually direct.
15. A common server-side coding mistake is to set a cookie and then refer to the cookie value within the same server response – yet the cookie would not have been activated until the response had been sent.
16. Some web servers (including Apache) restrict cookie data length, refusing to server data if the length is exceeded.
17. Cookie names should not contain certain special characters like '=' as these have special meanings within HTTP and there is no standard escaping mechanism for cookie names. (Unexpected bugs may happen if you attempt to set such cookies)
18. Cookies were invented by Netscape, not by the usual standards bodies (the IETF or W3C).
19. On some web servers it is not possible to set a cookie at the same time as doing an HTTP redirect.
20. The name 'cookie' was given for no particular reason, but is the origin of endless bad jokes.

See also

• https://www.youtube.com/watch?v=mI2STe_Kklk
• Nuances of forum integration
• Security
• Guide to web technologies (including HTML, CSS, and JavaScript)
• How the Internet works
• Understanding and configuring e-mail
• How domain names work

Feedback

Have a suggestion? Report an issue on the tracker.