Rules for plugins using sessions

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Rules for plugins using sessions

Post by cmb » Mon Dec 08, 2014 8:20 pm

Hello Community,

it seems rather important to set forth some rules regarding the usage of sessions, which should be adhered to by all extensions (plugins, addons and templates), because the sessions are usually shared between the core and all involved extensions. The only rule that we currently have is documented in the developers manual in the Wiki:
never destroy a session; it might still be used by others
However, this is not sufficient, because there are more things that should be avoided:
  • using unprefixed keys of the $_SESSION array (what could lead to collisions between otherwise unrelated functionality)
  • changing or even deleting session variables which one doesn't own
  • calling session_reset() (available since PHP 5.6)
  • changing of session settings, such as session.save_path, session.cache_expire etc.
  • starting a session even when not required for the current request
  • storing lots of data in the session
  • starting a new session with another ID and/or name (for rare exceptions see below)
Most likely this list is incomplete, and a whitelisting approach (i.e. defining what is allowed) is preferable:
  • starting the session if not already started (if (session_id == '') start_session;)
  • storing and retrieving of properly "namespaced" keys which belong to the extension
  • retrieving values which belong to other extensions (if absolutely necessary)
Usually that should be sufficient. Everything else might better be handled by the core resp. made available via some additional core APIs. In very rare cases an extension might take advantage of having its own session (GXSecurity is such an extension); then it might be okay if the plugin closes an existing session, starts its own, closes it later, and restarts the general session. However, by default session files are locked while the session is open to avoid problems due to concurrent access by the same user (what otherwise could be an issue with Ajax requests, for instance), so it is preferable to stick with the general session.

Note that we have Use named Sessions on the roadmap, what does not directly affect the above rules, but is nonetheless related to this topic.

What do you think? Can we agree on some rules?

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply