Server-side sessions

If you select the Server-side sessions option when generating your codebase, the application will be configured to support session management using the alexedwards/scs package.

Because session data is stored server-side in the database, you will need a sessions table to store it.

If you selected the option to include SQL migrations when generating your codebase, the migration for creating the sessions table is in the assets/migrations/000002_create_sessions_table.up.sql file. It will be created automatically when you first run the application, or execute make migrations/up from the admin Makefile.

If you didn’t include SQL migrations, you will need to create the sessions table manually. Please see the setup instructions for SQLite, PostgreSQL, and MySQL.

Using and configuring sessions

For full details on how to use sessions in your code, please see the alexedwards/scs documentation. But at its simplest, you can add and retrieve data from the a session like so:

func (app *application) exampleHandler(w http.ResponseWriter, r *http.Request) {
    ...

    // Add the key "foo" and value "bar" to the session.
    app.sessionManager.Put(r.Context(), "foo", "bar")

    // Retrieve the value for the key "baz" from the session.
    baz := app.sessionManager.GetString(r.Context(), "baz")    
    ...
}

By default, sessions are set to expire after 1 week. You can change this – along with other settings – in cmd/web/main.go by configuring the sessionManager values. For example:

sessionManager := scs.New()
...
sessionManager.Lifetime = 3 * time.Hour
sessionManager.IdleTimeout = 20 * time.Minute

Note: Autostrada follows good security practices for session cookies, by default setting the Secure, HttpOnly and SameSite=Lax attributes on the cookie. In modern versions of Chrome, Firefox and Edge, localhost addresses are considered secure for the purpose of the Secure flag, even if you're not using HTTPS. This means that the default settings should work out-of-the-box in most development environments. However if you are using Safari, you may need to set sessionManager.Cookie.Secure = false during development or switch to using an alternative browser.

Session cookie name

By default, each generated application uses a unique session cookie name in the format session_{8 random characters}, such as session_dym2nwnr. The random suffix helps reduce the risk of cookie conflicts when developing multiple applications on the same machine.

When running your application in production you may want the session cookie to have a different name, and you can do this via the configuration settings.

If you're using command-line flags for configuration, use the --session-cookie-name flag when starting the application. For example, if you want to change the session cookie name to sid:

$ go run ./cmd/web --session-cookie-name="sid"

If you're using environment variables, set SESSION_COOKIE_NAME like so:

$ export SESSION_COOKIE_NAME="sid"