Skip to main content

Session management

Initialising sessions

Sessions are managed by the TfSession class.

Sessions are initialised in tfish_header.php, which calls TfSession::start() and must be included on every page after mainfile.php. Include the first two lines as the first order of business on every public-facing page:

// Access trust path, DB credentials and preferences. These files must be included in *ALL* public-facing pages.
require_once TFISH_PATH . 'mainfile.php';
require_once TFISH_PATH . 'tfHeader.php';

On administrative (back end) pages, where only the site administrator is allowed, use tfAdminHeader.php instead. This is basically a wrapper for tfHeader.php except that it does an additional admin check (and will exit if user is not logged in):

// Access trust path, DB credentials and preferences. These files must be included in *ALL* administrative pages.
require_once "../mainfile.php";
require_once TFISH_ADMIN_PATH . "tfAdminHeader.php";

Session security

The TfSession::start() method sets session cookie parameters as follows:

  • Sessions are locked to cookies, to avoid the possibility of session ID being passed as a query string parameter, which is a session hijacking risk.
  • The name of the session and session lifetime as set as per the Tuskfish preferences and can be customised. The defaults are 'tfish' and 20 minutes, respectively.
  • Session cookies are enabled over all paths and subdomains.
  • If the site is running under SSL then Tuskfish will pass the cookie via encrypted (https) protocol; and obviously if it isn't, then it won't. These days you should always be running websites over SSL.
  • Tuskfish will attempt to set the httponly flag when passing the cookie.

TfishSession implements a few additional measures to try and improve session security:

  • The session ID is regenerated on privilege escalation (admin login), if the remote client's IP address or user agent (browser) changes, and randomly (10% chance per page load).
  • If an IP or user agent change is detected, session data will also be reset.

Admin authentication

Passwords are hashed using PHP's native password_hash() function with the default Bcrypt algorithm and a cost of 11. This automatically salts and iterates the hash calculation. The salt and cost information are prepended to the hash and stored together in the same column of the user table. Passwords are verified with the native password_verify() function.

On the administrator successfully logging in Tuskfish will set a flag $_SESSION['TFISH_LOGIN] = true. To test if the current session is the administrator call TfSession::isAdmin(). This will return true if the session is the (logged in) administrator and false otherwise. As an example of usage, this is how the admin check is done in tfish_admin_header.php:

/** CRITICAL - ADMIN CHECK - DENY ACCESS UNLESS LOGGED IN. */
if (!TfSession::isAdmin()) {
    TfSession::logout(TFISH_ADMIN_URL . "login.php");
    exit;
}

Note that if you include tfAdminHeader.php at the beginning of a page (instead of tfHeader.php) then you get the admin check automatically.

Copyright, all rights reserved.

Related

Tuskfish CMS Developer Guide

This guide will give you an overview of the architecture of Tuskfish CMS, how to write code to perform common operations and how to extend the system to suit yourself. The guide accompanies theĀ Tuskfish API documentation. Keep a copy handy as you read this guide. It is best to review links to the API where provided, as not every detail will be discussed in the text. This is the first version of the guide, so it is still a work in progress.