Cleaning up session use is on the table for the next major FarCry release and I thought I would post my notes so far here. The focus will be on:
- removing session dependence from forms
- supporting disabled sessions on public websites
- improving session extensibility (e.g. custom session storage)
Current core use
This is an attempt at a comprehensive review of session use in Core. It might be useful to discuss patterns of session use in plugins too.
mode: contains various "sticky" options, like debug mode, cache bypassing, and admin status; mainly used in reference to logged in users, though some of these options can be enabled without logging in (e.g. debug mode); this should only be used to set a similar structure in
loginMessage: used as a way of overriding login error messages - doesn't seem to be used in Core; might have been added to support plugin functionality?
stFilters: used by contentAdmin tags for filter persistence; only used in
stList: contains attributes for a customAdmin list; only used in
trayWebskin: override for tray webskin; it isn't clear why this is overridable per-session, as opposed to per-project
setData use this for storage
- used as a switch for:
- writing the lock flag to the db
- inappropriate archiving
process in forms
ft:objectadmin: storing filter data
ft:processformobjects: storage of content that failed validation
farRole: postpones saving wddx packets until the primary object is saved
- formtool ajax functionality: so that code can access values entered in the form as normal, without it actually being saved
key='...', usually for views and forms that are creating new content to work with re-displaying forms that failed validation
dmArchive: for viewing archived content
coapiUtilities: checks this struct in
findType; NOTE: the typename is then stored in the application scope - permanently
Deprecated: no longer set or used as of FC7.2.
Basically a cache for user permission and role lookups. Generally only relevant for logged in users.
NOTE: there is duplicate funtionality between
session.security.firstlogin for backwards compatability.
Cache for user profile. Generally only relevant for logged in users.
Deprecated: all the functionality I can find that uses this scope is no longer used by FarCry.
ft:objectadmin and passed to
farcry/objectadmin.cfc to populate with defaults and other stuff. It isn't clear where the data is actually used.
Used entirely by
ft:objectadmin for filter form persistence.
facade/library.cfm, which don't appear to be used by anything ...
ft:objectadmin for pagination persistence.
ft:object to make it possible to have an object webskin / form for content that doesn't exist yet, particularly for re-displaying after invalidated form posts.
ft:form to share spam settings with
Used for user impersonation, mainly by the
skin:pop to persist messages across page redirects.
url.ref, which is set in many places, and used by various dialogs to know where to return to after save.
session.dmProfile.locale and used in the webtop:
<html dir="#session.writingDir#" lang="#session.userLanguage#">
forgotPasswordReset webskin as a security measure in the reset workflow.
Most of the current session variables should be moved to the
fc variable. This could be done via functions in the
session library. All of these use cases could be refactored to work with a get and a set function that take a "namespace" and a key. e.g.:
tempObjectStore + UUID
If these references also included defaults relevant to anonymous or sessionless users, this would allow FarCry to disable session. Either on the entire front end, or for specific users.
There are three session dependencies in forms:
tempObjectStore for storage of submitted results, especially when validation fails and the form needs to be displayed again; also for use with
stFarCryFormSpamProtection to reduce duplication of spam settings between
stTempObjectStoreKeys to simplify
displayBodyCreateAThing webskins and the forms they contain
Temporary storage between form rendering can be removed by changing
ft:processform to put the processed form data in the request scope, and
ft:object to look for that data. We can't use the form scope directly because there is an intermediate processing step through formtools which converts posted data into consistent formats. NOTE: there are a few projects that use the current "implied" persistence to support wizard-step like functionality. If we do implement this change, those projects would need to be changed to explicitly persist the data in the session themselves.
The spam issue comes up because a site may enable spam detection on some forms but not others. In these cases we could say that developers have to explicitly set the spam settings on both the
ft:form and the
Accessing objects (see
ft:object) by key instead of objectid could be supported by saving the key=>objectid relationship as a form field. This would mean that the object would only persist across form posts, rather than all requests. At the moment these forms "remember" the previous data if a user leaves and returns to the page.
These changes don't remove
tempObjectStore, which is a useful feature. They just remove it from the default behaviour of FarCry forms.
Other session use
The following variables could potentially be refactored to not require session:
objectadmin - these variables seem to be used in the same request
fc.trayWebskin - project setting, not session
ajaxUpdatingArray - remove unused templates
stLibraryFilter - remove unused templates
resetPWUserID - signed value in form