Remove dependency on sessions


The module is dependent on sessions to work. They are used for the history component, and references are found in these files:

Since most REST APIs should have sessions turned off by default, this creates an issue. One can go around the issue by creating environment settings that turn on and off the sessions for production, but I would love to not have to do that and just have the module work by dropping it into a new project.

The sessions also seem to affect the functionality of the RelaxURL part at "/relax/relaxer" (URL ending if you have Relax installed). Without sessions, the "Send Request" does not work.


Jon Clausen
February 15, 2016, 3:56 PM

PR#43 Removes the session dependency, with a few caveats:

Since Coldbox's flash system defaults to session storage, the following functionality is disabled when session storage is unavailable:

  • Import capability

  • The ability to switch between APIs. Since the session currently tracks the loaded API variable, there is no way to switch between APIs. As such, the default configured API becomes the only one available.

Once the epic is completed, we'll be able to handle messaging and API loading from within the UI, so this functionality will be re-enabled.

Luis Majano
February 16, 2016, 4:42 AM

I was thinking to use cookies instead. Was this the way it was implementeD?

Jon Clausen
February 16, 2016, 4:50 AM

I was operating under the assumption that if the app was going to be truly stateless, the setClientCookies option would be disabled as well. I can manually set cookies, but it would not be truly "stateless", in the strict sense of the word and any visitor with disabled cookies would throw errors.

The way this PR is implemented, anything that requires state to be maintained is being bypassed (e.g. the coldbox flash scope) or hidden from the UI (e.g. disabling import functionality). The original implementation uses the session scope, exclusively - which is also the Coldbox default flash storage scope.

Once we finish RELAX-1, we can use the browser window to maintain state and provide messaging rather than the current CFML request/response implementation.

If you'd like to implement this with cookies, just let me know. It opens up another rabbit hole of error handling, but wouldn't be difficult to implement.



Jon Clausen


Evagoras Charalambous



Fix versions