HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

ocPortal Tutorial: Introduction to Cookies and sessions (and Javascript)

Written by Chris Graham, ocProducts
This is a tutorial that will explain the concept of cookies and sessions, as well as briefly explain how they relate to Javascript in ocPortal.



Cookies

A cookie is simply 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 registered, 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+computer-account they accessed with
  2. it would allow client-side web applications to have a memory, which was otherwise impossible

There is a drawback to (1) however, and that is, unless additional work is done, the identification is not able to be faked by someone replicating the same cookies someone else has. For example, if the username was stored as a cookie, a hacker knowing the username would be able to simply use the same cookie themselves: hence becoming another user.

Login cookies

It is clearly necessary that cookies contents are not predictable. 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 unless they know it in the same sense you might know someone's password, 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.

Sessions

Technical note

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 specific access privileges.
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 ocPortal user identification. Once a user is established to be a guest, or they have logged in manually, 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-id.

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 user's IP address often changes. ocPortal does however make it so a session cookie will only work if it has been 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 separate from Java, and built into web browsers directly. It is used to provide an interactive element to the user's experience in their web browser.

ocPortal detects Javascript by making the web browser write a cookie using Javascript. If such a cookie exists, ocPortal knows Javascript is enabled as there would be no other normal way that cookie could come to exist. Likewise, if the cookie does not get set, ocPortal knows Javascript is probably not enabled.
Whilst 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 it's presence to web servers directly.

If ocPortal says Javascript is not enabled it can mean three things:
  • Javascript truly isn't enabled (whilst 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)
  • Session Cookies are disabled
  • The ocPortal cookie settings chosen at installation are not 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.

If the problem is number 1, then you can adjust the browser settings to reenable Javascript. In Internet Explorer, the setting you need is under the "Security" options tab.

Privacy

Basically, 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 view visited on their network. Therefore as more paranoid user's may feel the need to disable their cookies, ocPortal does not require them: session details may be relayed by URL in ocPortal. 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 ocPortal 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.

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.



Concepts

Cookie
A piece of data stored on a users computer related to your website, and passed to your web server whenever the user access it
Session
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

See also