Reduce session use in Core

feature spec
1

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.

fc

  • 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 request.mode
  • 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 customAdmin:displayFilter
  • stList: contains attributes for a customAdmin list; only used in customAdmin:list
  • trayWebskin: override for tray webskin; it isn’t clear why this is overridable per-session, as opposed to per-project

tempObjectStore

  • forms: getData and setData use this for storage
  • used as a switch for:
    • writing the lock flag to the db
    • inappropriate archiving
    • calling 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
  • ft:object and skin:view: with 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

dmSec

Deprecated: no longer set or used as of FC7.2.

security

Basically a cache for user permission and role lookups. Generally only relevant for logged in users.

NOTE: there is duplicate funtionality between session.firstlogin and session.security.firstlogin for backwards compatability.

dmProfile

Cache for user profile. Generally only relevant for logged in users.

typeadmin

Deprecated: all the functionality I can find that uses this scope is no longer used by FarCry.

objectadmin

Used in 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.

objectadminFilterObjects

Used entirely by ft:objectadmin for filter form persistence.

ajaxUpdatingArray and stLibraryFilter

Used by facade/library.cfc and facade/library.cfm, which don’t appear to be used by anything …

fcpagination

Used by farPagination.

ftPagination

Used by formtools.cfc and ft:objectadmin for pagination persistence.

stTempObjectStoreKeys

Used by skin:view and 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.

stFarCryFormSpamProtection

Used by ft:button, ft:form to share spam settings with ft:processform.

sessions and impersonator

Used for user impersonation, mainly by the session lib.

aGritterMessages

Used by skin:bubble and skin:pop to persist messages across page redirects.

overviewRef

Persists url.ref, which is set in many places, and used by various dialogs to know where to return to after save.

writingDir and userLanguage

Based on session.dmProfile.locale and used in the webtop:
<html dir="#session.writingDir#" lang="#session.userLanguage#">

resetPWUserID

Used by forgotPasswordReset webskin as a security measure in the reset workflow.

Changes

Consolidate into fc

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.:

  • security + profile
  • ftpagination + dmNews
  • tempObjectStore + UUID
  • mode + debug

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.

Forms

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 stTempObjectStoreKeys
  • stFarCryFormSpamProtection to reduce duplication of spam settings between ft:form and ft:processform
  • 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 ft:processform tags.

Accessing objects (see skin:view and 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
2 Likes