Sessions

Overview

Geddy has sessions built in. This gives you a way to associate data with a particular visitor to your app, and have that data persist between requests.

Note that if you use sessions, there will be a session created for each visitor to your app. This is not the same thing as an authenticated user. Of course if you wish, once you've authenticated users, you can save their authenticated status in the session.

Session data-stores

Geddy offers a number of different ways to persist session-data:

• Memory (the default): useful mostly for development. Session-data is saved at the worker-process level, so in-memory sessions cannot be used with a Geddy app and multiple worker-processes. Also, all sessions disappear when the app is restarted.

• Cookie: Session-data is passed back and forth in (encrypted) cookies in the request/response. Sessions will persist when the app restarts, but the amount of data you can save in a session is much more limited.

• Memcache: Requires a Memcache server or cluster. Uses Arnout Kazemier's 'memcached' module.

• Redis: Requires a Redis server or cluster. Uses Matt Ranney's 'redis' module.

You will probably want to develop with in-memory sessions, and use cookie, Memcache, or Redis sessions for production (depending on how much data you want to save in the session).

If you don't wish to use sessions, simple set the 'sessions' property in your application's configuration to null.

Using sessions

The session-object is available on the Geddy controller-instance, and has a get and set method. Here's an example of an incrementing counter saved in the session:

var Main = function () {
  this.index = function (req, resp, params) {
    var counter = this.session.get('counter');
    if (!counter) {
      counter = 0;
    }
    counter++;
    this.session.set('counter', counter);
    geddy.log.debug(counter);
    this.respond(counter, {
      format: 'txt'
    });
  };
};

exports.Main = Main;

Session-data is saved into the data-store at the end of the request/response cycle, before the response is completed. Any I/O required (depending on the specific data-store) is performed asynchronously.

Session configuration

Each type of data-store will have its own specific config-properties, but there are a few that are common to all types:

• 'store': The type of data-store (e.g., 'memcache', 'cookie'). Default is 'memory'.
• 'key': The name used for the session-identifier cookie. Default is 'sid'.
• 'expiry': How long a session will last (in seconds) if it goes unrefreshed. Default is two weeks.

Other properties are data-store specific.

Sample configurations

Memcache

// 'servers' is your array of Memcache servers.
, sessions: {
    store: 'memcache'
  , servers: ['127.0.0.1:11211']
  , key: 'sid'
  , expiry: 14 * 24 * 60 * 60
  }

Redis

// 'server' is your Redis server.                                                     
, sessions: {                                                                         
    store: 'redis'                                                                    
  , server: {                                                                         
      host : "127.0.0.1"                                                            
    , port : 6379                                                                   
    , opts : {}                                                                     
    , auth : "megasecret" // [optional] password                                    
    , ns  : "sess:" // redis key prefix                                             
    }                                                                                   
  , key: 'sid'                                                                        
  , expiry: 14 * 24 * 60 * 60  
  }

Cookie -- note: cookie-based sessions use encrypted session-data, and depend on having an app-secret set in your 'environment.js'. Run geddy secret to set this up.

, sessions: {
    store: 'cookie'
  , key: 'sid'
  , expiry: 14 * 24 * 60 * 60
  }