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.
Following is what usually meant by "session" in a scope of web-development. First example is a definition of php session from w3schools:
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:
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.
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%
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:
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.