Dancer...bstract(3pm)

πŸŽ€ Dancer::Session::Abstract πŸ’…

okay bestie, so this is Dancer::Session::Abstract from the 3pm manual β€” it's a Perl module and it's like, the blueprint energy, not the actual doer, iykyk. ✨

✨ VERSION ✨

version 1.3522 β€” yes she's got a number, she's official. 🫢


🌸 DESCRIPTION 🌸

So basically this is a virtual class β€” a whole vibe of a class that describes how to build a session engine for Dancer. The reason it exists? So you can have a bunch of different session storage backends all living their best lives with one common interface. Slay. πŸ’–

Any session engine out there MUST inherit from Dancer::Session::Abstract and MUST implement these abstract methods down below. That's the rule, no cap. πŸ‘‘

πŸ“ Configuration πŸ“

These settings control how a session acts. Like, the personality settings. πŸ’…

session_name

The default session name is "dancer_session". You can set it in your config file like this:

setting session_name: "mydancer_session"

session_domain

This one lets you set the domain property on the cookie, and it overrides the default. Super useful when you want the session cookie's domain to be something like ".domain.com" so that the same cookie is applicable and usable across subdomains of a base domain. Iconic for sharing. 🌈

session_secure

The user's session id is stored in a cookie. If this is true, that cookie gets made "secure" β€” meaning it will only ever be served over https. Locked down, protected, main character energy. πŸ”’

session_expires

When should the session expire? The format is either the number of seconds in the future, or the human readable offset from "expires" in Dancer::Cookie.

By default, there is no expiration. She lives forever, apparently. πŸ’€

session_is_http_only

This setting defaults to 1 and it instructs the session cookie to be created with the "HttpOnly" option active β€” which means JavaScript will not be able to access its value. Bye bye, snooping scripts. πŸ™ˆ

πŸ¦‹ Abstract Methods πŸ¦‹

These are the ones you have to implement, bestie. No skipping. 😀

  • retrieve($id) β€” look for a session with the given id; return the session object if found, undef if not.
  • create() β€” create a new session, return the session object.
  • flush() β€” write the session object to the storage engine.
  • destroy() β€” remove the current session object from the storage engine.
  • session_name (optional) β€” returns a string with the name of the cookie used for storing the session ID.

You should probably not override this one; the user can control the cookie name using the "session_name" setting. (She said what she said.)

  • get_value($key) β€” retrieves the value associated with the key.
  • set_value($key, $value) β€” stores the value associated with the key.

✨ Inherited Methods ✨

These ones are not supposed to be overloaded. They're generic and should be totally OK for every session engine out there. Leave them alone, they're doing great. 🫢

  • build_id β€” build a new uniq id. ✨
  • read_session_id β€” reads the session ID from the cookie, ensuring it's syntactically valid.
  • write_session_id β€” write the current session id to the "dancer.session" cookie.
  • is_lazy β€” default is false. If true, session data will not be flushed after every modification, and the session engine (or the application) will need to ensure that a flush is called before the end of the request. So if you turn this on, the responsibility is yours, bestie. πŸ‘€

🌈 SPEC 🌈

role

A Dancer::Session object represents a session engine and should provide anything needed to manipulate a session, whatever its storing engine is. Versatile queen. πŸ’œ

id

The session id will be written to a cookie, by default named "dancer.session", and it is assumed that a client must accept cookies to be able to use a session-aware Dancer webapp. (The cookie name can be changed using the "session_name" config setting.) πŸͺ

storage engine

When the session engine is enabled, a before filter takes care to initialize the appropriate session engine β€” according to the setting "session".

Then, the filter looks for a cookie named "dancer.session" (or whatever you've set the "session_name" setting to, if you've used it) in order to retrieve the current session object. If it's not found, a new session object is created and its id is written to the cookie. Fresh start energy. ✨

Whenever a session call is made within a route handler, the singleton representing the current session object gets modified.

A flush is made to the session object after every modification β€” unless the session engine overrides the "is_lazy" method to return true. 🧚

⚠️ lowkey important: if is_lazy says true, the automatic flushing stops happening, so you'd better make sure a flush goes out before the request ends. no cap.

πŸ‘‘ AUTHOR πŸ‘‘

Dancer Core Developers β€” legends, honestly. 🫢


This software is copyright (c) 2010 by Alexis Sukrieh.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.


and that's the whole page, bestie πŸ’… she's perl v5.40.1, dated 2026-05-05, filed under Dancer...bstract(3pm) β€” go build a session engine, you got this πŸ¦‹πŸŒΈβœ¨

πŸ“¦ where this page comes from