Seaside sessions are not what they seem!

If you worked with Smalltalk Seaside framework, you know that there is an object called "Session" which you can use to store a global state for your application. For instance, you may have a current user object stored and shared between components in session. If you use it, you must know that name "session" is very misleading and dangerous as "session" in other platforms means completely different thing than it means in Seaside. Understanding the difference is essential for security and usability of your application. In this article, I would like to show the difference between "usual session" and "seaside session" and why cookie-tracking policy should not be used for "securing" the urls.

Session in common sense

Following is what usually meant by "session" in a scope of web-development. First example is a definition of php session from w3schools:

A PHP session variable is used to store information about, or change settings for a user session. Session variables hold information about one single user, and are available to all pages in one application.

The same meaning we can find at Django documentaiton. They have not bothered to make a definition on the term "session" as it is obvious for a web-developer. Check it out:

This session framework lets you store and retrieve arbitrary data on a per-site visitor basis. It stores data on the server side and abstracts the sending and receiving of cookies.

So "usual session" is an object which is shared for requests made by one user during a period. If you open a site in 10 tabs all of them share one session. If you open a new tab pointing at the root of the site - no difference, it is the same session.

Session in Seaside

Seaside is made state-full which means Seaside maintains a state of user interaction flow with a web-application. Therefore, one user may have simultaneously several flows of interaction (for example, in different tabs). By "session" in Seaside means each separate flow. Session object is not shared across all tabs you open but only inside one flow.

Therefore, if we link "usual session" term to "seaside session" we may say following is true:

"Usual session" may have many "Seaside sessions" inside.

So every time you open Seaside application with a root url (without _s and _k query parameters) you are starting a new flow. This means if you logged in to a web-application, and you eventually clicked on "home" button (a link to root "/") - your session is lost as you just started a new flow and you have to log in again.

So what do you do in this case? Well you probably go and see what options Seaside provides you. You may find a cookie-based session tracking strategy in a configuration of you application and you may think it is what you want.

No. Cookie based session tracking strategy is not what you are looking for, %username%

Why cookie-based session tracking is bad

As mentioned before Seaside session is not a "usual session" but just one flow. By applying cookie-based session tracking strategy, you make Seaside store _s in a browser cookie. As a result, a browser is be limited to ONE Seaside session as the cookie shared between tabs. This means that the browser is not capable of maintaining several flows of users interaction.

If you open a web application with cookie-based session tracking strategy in several tabs - the tabs will interfere with each other.

Seaside is not just storing your application-specific information inside Session object but the whole state of user-app interaction flow. If you look into the code, you may notice that a link to an instance of a root component is stored in session object so when session is reinitialized this property is rewritten.

This means if you do some stuff in one tab and then you open a root of the site in other this will cause following:

  1. New tab will initiate the flow to be reset (as there is no _k parameter). Therefore, you get brand new instances of root component in new tab and this is what you expect to happen. However, the problem is that the root object is re-written in Session object (which is shared with the other tab)
  2. Old tab is used at some point, but state of the flow is lost as the root object was re-written by other tab. You may see all kind of inconsistent behavior at this point but the main problem that your work is lost: the new tab interfere.

I doubt that limiting a user to one tab is what you want. I strongly recommend testing before you go with cookie-based session tracking in Seaside. Some better solution for Session in Seaside should be proposed eventually... but now we have to create our own hacks to do stuff.