Skip to content

Sessions in Silgy

Jump to bottom
Jurek Muszyński edited this page Oct 16, 2019 · 35 revisions

Overview

Silgy provides a session mechanism.

A session can be in one of the two states: anonymous or logged in. Anonymous session is identified with as cookie, whereas logged in with ls cookie.

There are two factors affecting whether the first HTTP request from a client starts a session or not:

  1. Default resource authorization level for the entire application, set with DEF_RES_AUTH_LEVEL. If not set, it's AUTH_LEVEL_NONE, which means that – unless set with silgy_set_auth_level() – there are no sessions.

  2. Authorization level set for a particular resource with silgy_set_auth_level(). It has a priority over DEF_RES_AUTH_LEVEL.

Authorization levels

Authorization level is one of the resource's and the session's property. They can have one of the following values:

macro value notes
AUTH_LEVEL_NONE 0 No user session is required.
AUTH_LEVEL_ANONYMOUS 1 Anonymous user session is required. If there's no valid as cookie, anonymous user session is started.
AUTH_LEVEL_LOGGEDIN 2 Logged in user session is required. If request does not have valid ls cookie, it's redirected to URI defined in silgy_app.h APP_LOGIN_URI.
AUTH_LEVEL_USER
AUTH_LEVEL_CUSTOMER
AUTH_LEVEL_STAFF
AUTH_LEVEL_MODERATOR
AUTH_LEVEL_ADMIN
AUTH_LEVEL_ROOT		 10
20
30
40
50
100		 User has to have at least matching auth_level. Otherwise request will receive 404 (security by obscurity).
AUTH_LEVEL_NOBODY 125 Provided for whitelist-based access model, when high security is required. If DEF_RES_AUTH_LEVEL is set to AUTH_LEVEL_NOBODY, only resources explicitly set via silgy_set_auth_level() will be accessible.

Static resources always have AUTH_LEVEL_NONE.

Session data structures

There are two data sets holding session information:

  1. Engine, defined in silgy.h

    typedef struct {
    /* id */
    char    sesid[SESID_LEN+1];
    /* connection data */
    char    ip[INET_ADDRSTRLEN];
    char    uagent[MAX_VALUE_LEN+1];
    char    referer[MAX_VALUE_LEN+1];
    char    lang[LANG_LEN+1];
    bool    logged;
    /* users table record */
    int     uid;
    char    login[LOGIN_LEN+1];
    char    email[EMAIL_LEN+1];
    char    name[UNAME_LEN+1];
    char    phone[PHONE_LEN+1];
    char    tz[6];
    char    about[ABOUT_LEN+1];
    int     group_id;
    char    auth_level;
    /* CSRF token */
    char    csrft[SESID_LEN+1];
    /* internal */
    time_t  last_activity;
} usession_t;

  2. Application, defined in silgy_app.h

    typedef struct {
    char dummy;     // replace with your own struct members
} ausession_t;

    This part is meant to be extended by a framework user.

Session vs Connection

If a session has been created, every active connection keeps the pointer to it. Therefore, connection index (ci) can be used to access current session data. US and AUS macros are provided for this.

Upgrading / downgrading the session

These terms are used to indicate session state change.

  • Upgrade means switching the session state to logged in, after successful authentication. The engine then calls silgy_app_user_login().

  • Downgrade means switching the session state back to anonymous. The engine then calls silgy_app_user_logout().

LOGGED macro can be used to check whether current session is in logged in state.

Closing the session

Anonymous session is closed after session had been inactive for USES_TIMEOUT seconds or silgy_app_session_init() returned false.

Logged in sessions are not closed but downgraded to anonymous. This can happen either by calling silgy_usr_logout() or after being inactive for LUSES_TIMEOUT seconds.

ASYNC requests

User sessions are shared between the master (silgy_app) process and the services (silgy_svc). If the application part of the user session exceeds G_async_req_data_size, messages' sizes may need to be increased. See Data Exchange paragraph in ASYNC for details.

Clone this wiki locally