Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Cookieless Sessions.

Cookieless Sessions

From MoodleDocs
Revision as of 13:00, 11 October 2010 by Petr Škoda (škoďák) (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Moodle1.6


NOTICE: The cookieless mode significantly reduces security of your Moodle installation. It was designed only as a workaround for mobile phones that did not support session cookies. Some standard Moodle features do not work in this mode, it is considered to be an experimental feature.

In Moodle 1.6 we've added support for cookieless sessions to Moodle. The code will need testing in the different modules to check that it works in all areas of a site. You can test it by turning cookies off in your browser or disallowing cookies just for your Moodle site. Post any bugs you find here : http://tracker.moodle.org/browse/MDL-4504

Cookieless sessions work by appending a session id to every url or to hidden form fields in forms in html pages so that php can track sessions. When cookieless sessions are turned on then code in lib/cookieless.php will automatically add session ids in the absence of cookies. The code will fail when javascript is used to jump from page to page. So when using javascript to jump to a new page then you can call a function in lib/cookieless.php to add session ids to the URL, as follows :

   if (!empty($CFG->usesid) && !isset($_COOKIE[session_name()])) {
       $attempturl=sid_process_url("attempt.php?id=$cm->id");
   } else {
       $attempturl="attempt.php?id=$cm->id";
   };

You don't need to include cookieless.php it will have been included already if needed.


Enable cookieless sessions by including $CFG->usesid=true; in config.php. Based on code from php manual by Richard at postamble.co.uk

Attempts to use cookies if cookies not present then uses session ids attached to all urls and forms to pass session id from page to page. If site is open to google, google is given guest access as usual and there are no sessions. No session ids will be attached to urls for googlebot. This doesn't require trans_sid to be turned on but this is recommended for better performance you should put session.use_trans_sid = 1 in your php.ini file and make sure that you don't have a line like this in your php.ini: session.use_only_cookies = 1

author Richard at postamble.co.uk and Jamie Pratt license http://www.gnu.org/copyleft/gpl.html GNU Public License

Turning off cookies completely

By default this code tries to use cookies still and falls back to using url parameters to pass the session id if cookies are not present.

You can turn off cookies completely for your Moodle server by adding the editing the setting in php.ini file for "use_cookies", so it says :

session.use_cookies = 0

Security

Especially if your users are using shared computers this can reduce the security of Moodle.

Following warning is from php.ini file :

trans sid support is disabled by default.
Use of trans sid may risk your users security.
Use this option with caution.
- User may send URL contains active session ID
to other person via. email/irc/etc.
- URL that contains active session ID may be stored
in publically accessible computer.
- User may access your site with the same session ID
always using URL stored in browser's history or bookmarks.

It is probably best to time out the sessions fairly quickly to reduce the risk of people using shared computers having access to others sessions and being able to log in as them. Use the sessiontimeout setting in the admin menu and set it to as low a number as possible (but remember it can be frustrating for your users to spend a long time on a forum post and then find they lose the post when they try to save it because the session has timed out).

Importantly users should be informed it is important to log out when they have finished their session and not to send urls with their session id in it to others. Closing the browser window instead of logging out will not be sufficient to stop someone else trying to log in to that users account using urls in the browser history.