We probably need a general mechanism to handle sessions:

• by cookies? (but we raise the browser requirements)
• by url rewriting

Pro

• we can handle variables kept along the user session

Url rewriting is probably the easiest way (we are already rewriting the whole topic at each click).

Ideas

• We could use a hidden field that is post/get at each click
  • we must convert all links to submit buttons
  • we can use javascript to change field's stored values
• we could just rewrite all internal links
  • I am not sure we can change the values at will

-- AndreaSterbini - 13 Sep 2000

What are the reasons to keep track of a session? I opt for keeping it stateless unless there are compelling reasons otherwise.

• Cookies do not always work (not supported or disabled) and are controversial. It would be OK if the funtionality would downgrade gracefully for non cookie browsers.
• Including a session ID in the URL is simple to implement, but has the disadvantage that a URL is not identifying a TWiki page uniquely anymore. At work it happens many times that a TWiki URL is sent in an email.

-- PeterThoeny - 13 Sep 2000

I am not thinking to a session ID, but rather to a set of varname=value pairs.

• the url mantains its meaning (you can send it, you can bookmark it)
• TWiki can do variable substitution also on the variables so defined
• A user, instead that edit his/her topic to change her settings, could just flip some choice/radio/combo box and submit a GET action in a form.

Example

This rewritten url mantains the user information when he/she uses view and sets the preferred web color to #00FF00:

   http://.../view/Codev/SessionVariables?WEBBGCOLOR=#00FF00&USERNAME=AndreaSterbini

Possible (easy) Implementation

• For all GET arguments add the name/value pair to the user's preferences
• Change the sub for internal links to add the parameters to the url

Pro

• This would solve the WhoIsTheRemoteUserInView problem (once the user is authenticated once).
• To be safe we must enforce SecurityAndVariableOverriding

-- AndreaSterbini - 14 Sep 2000

You just can't include a plain text 'USERNAME' in the URI without some form of authentication. Given that it is either no better than the standard browser user/password popup, or equalavent to some form of session management.

-- NicholasLee - 14 Sep 2000

I agree, the USERNAME example is a little silly. (But this way I can avoid the user is disoriented when has already edited some topic and then reads other topics and finds that his preferences are not applied ...)

BasicAuthentication remembers the user name only for authenticated pages. What I would like is:

• until I view pages only I am considered a guest,
• from the moment I identify myself to the system the system remembers my name and applies my preferences even for (non authenticated) view
• for security I am not using at all this remembered username for authenticated pages, (moreover, in authenticated pages the system knows the RemoteUser)

Apart from my silly problem, I think that some general session management mechanism would be helpful for making nice webs without too much hassles.

The simple implementation suggested is made such the user can use both preferences AND session variables exactly in the same way:

• the implementation is cleaner
• the user has a simple model of how to write a page (just use %VAR%)
• the system must not store/handle any session ID, because all the information is delivered in the URI (so, no session ID generation, storage, expiration problems)

... I will try to imagine some good example ...

Here is one:

• I would like to adjust the edit field width at runtime without editing my personal preferences
  • suppose the edit template has a field named EDITWIDTH
  • I can write in this field my desired width
  • this number is read by preview, then written in the URI
  • from now on it is used when edit a new topic (*)

-- AndreaSterbini - 14 Sep 2000

Problem is as soon as you start tracking the user, ie create state, you require a persistent mechanism. This is because http is a stateless protocol. So (*) above wont work without a storage mechanism.

Note since a TWiki device is the only thing likely to parse a TWiki URI it is possible to create unique TWiki URIs with embedded session keys. Just strip the sesion key before it gets passed to the content builder.

-- NicholasLee - 13 Feb 2001