This tutorial is mostly for interest, it is not required understanding for normal ocPortal use.
Table of contents
CookiesA 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:
- it would allow server-side web applications to identify a specific user by the computer they accessed with
- it would allow client-side web applications to have a memory, which was otherwise impossible
Login cookiesIt is necessary that cookies contents are not predictable, or people could simply re-create a cookie file on their own computer with the identity of a website administrator, for example. ocPortal 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.
ocPortal supports integration of login cookies with third party forum systems that run using an ocPortal 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.
Session for guests are actually using normal cookies, not session cookies. This is because they may need to be identified between visits if ocPortal has been extended with features such as a shopping cart system. There are less security ramifications for doing this for guests, as they have no special privileges.
Session cookies are used as the primary means of ocPortal 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. ocPortal 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).
- Session Cookies are disabled
- The ocPortal cookie settings chosen at installation are incorrect
Number 2 is the most likely cause, and this can be adjusted in the "Privacy" options of Internet Explorer: it is the simplistic "High privacy" slider that causes many users to disable cookies, when infact 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 ocPortal have a 'keep_session' bit in them then it means that session cookies are disabled.
If the problem is number 3, then you can adjust your cookie setting by opening up http://mybaseurl/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.
PrivacyCookies 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.
ocProducts recommends 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.
20 things you didn't know about cookies (for programmers)
- 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.
- 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.
- Session cookie XSS prevention security is lost if web browser tabs are used: the cookies don't expire because the browser is never closed.
- 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
- 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.
- Whilst 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, …).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Some web servers (including Apache) restrict cookie data length, refusing to server data if the length is exceeded.
- 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)
- Cookies were invented by Netscape, not by the usual bodies: the IETF or W3C.
- On some web servers it is not possible to set a cookie at the same time as doing an HTTP redirect.
- The name 'cookie' was given for no particular reason, but is the origin of endless bad jokes.
- A piece of data stored on a users computer related to your website, and passed to your web server whenever the user access it
- A session uniquelly identifies and provides continuality for a users website usage to a better degree than an IP address or cookie could (essentially, by using both together)
- Session Cookie
- A cookie that is deleted when the web browser is closed