Sessions

While the database is great for storing information long-term, sometimes you need to store and retrieve information very quickly for a user's current visit. For this use case, you can use the session object.

The Session Object

The session object is a Python key-value storage that is automatically passed to your component handlers, alongside the request and db objects.

PYTHON
def load_template_context(request, session, db, **props):
    # You can access the session object here
    views = session.get("views", 0) + 1
    session["views"] = views
    return {"page_views": views}

def action_add_to_cart(request, session, db, **props):
    product_id = request.form.get("product_id")
    cart = session.get("cart", [])
    cart.append(product_id)
    session["cart"] = cart
    return {"message": "Product added to cart!"}

The session object allows you to store and retrieve data that persists across multiple requests from the same user.

Session Backends

Noventa supports different backends for session storage, which can be configured in your config.yaml file.

Cookie-Based Sessions (Default)

By default, Noventa uses a cookie-based session backend. Whatever you store in the session object is saved into a client-side cookie. The data is cryptographically signed with your application's secret key (defined in config.yaml), so it cannot be tampered with or read by the user in their browser.

This is a simple and powerful option for storing a user's current session data or other simple information, but it is limited to the browser's cookie size limit (typically around 4KB).

In-Memory Sessions

If you need to store more information than a cookie can hold, you can use the in-memory backend. This backend uses the server's memory to store session information. This is very fast since it's running in the runtime, but it is not persistent.

All session data will be lost if the server restarts. This backend is also not suitable for production environments with multiple server instances, as a user's session would be tied to a single instance.

Redis Sessions

For a more robust and scalable solution, you can use Redis as a session backend. This allows you to connect to a Redis instance or cluster and store your session information persistently or in-memory, depending on your Redis configuration.

Session Configuration

All session options are configured in the config.yaml file. Here is a full example of the available settings:

YAML
session:
  # "cookie" for a client-side cookie store.
  # "memory" for a server-side, in-memory store.
  # "redis" for a server-side Redis store.
  backend: "cookie"
  # IMPORTANT: A secret string at least 64 characters long.
  secret_key: "yaapejgyojczvsvsrtuvyucfghwwhzpieelbcnxbhnqipnqioqqgelodbfwmpqdk"
  # The name of the cookie that will be sent to the browser.
  cookie_name: "noventa_session"
  # If true, the cookie will only be sent over HTTPS. (Set to true in production)
  cookie_secure: false
  # If true, the cookie cannot be accessed by client-side JavaScript. (Highly recommended)
  cookie_http_only: true
  # The URL path for which the cookie is valid. "/" means the entire site.
  cookie_path: "/"
  # Max age seconds
  cookie_max_age: 86400  # 1 day
  # Redis connection URL (used for session backend if enabled)
  redis_url: "redis://127.0.0.1/"
  redis_pool_size: 10

Security Considerations

While sessions are convenient for storing user data, remember:

  • Server-side validation: Always validate session data server-side - don't trust it for security decisions
  • Sensitive data: Don't store passwords, payment info, or other sensitive data in sessions
  • Session fixation: Be aware of session fixation attacks when implementing authentication
  • Cookie security: Use cookie_secure=true and cookie_http_only=true in production
  • Secret key: Keep your secret_key long (64+ characters) and secure

For user authentication, combine sessions with proper database-backed user management.