Sessions will mean user settings are always available - uses, see UsingSkins.

The main issues for TWiki is likely to be:

• Should we have them - I suggest making it configurable
• Should cookies or URL re-write be used - many people are wary of cookies and some browsers either can't process them or have support turned off. URL re-write is therefore more reliable, but not so good for copying and sending or URLs to others.
• Should the state of the session exist on the server (more secure) or within the browser (i.e. in cookie or within URL)

I suggest we supported cookie based sessions, but make it configurable as to whether this is used by a given TWiki site. Also, TWiki should continue to function happily without sessions. I suggest this is done via a plugin, so that different sites can configure as appropriate.

Also see: SessionVariables

-- JohnTalintyre - 04 Jul 2001

An optional cookie-based session handling based on a plugin sounds like a good approach.

-- PeterThoeny - 06 Jul 2001

Here is a list of good things that can be done with user sessions and variables (in the spirit of making sure that there is some gain for the pain of writing/configuring a session plugin)...

Short term...

• skins
• menus
• directory (eg ldap) integration
• enforce view access
• remove reliance on client IP addresses
• link to personal page

Medium term...

• favourites(sic)
• history
• searches
• statistics

Long term...

• group preferences
• jabber (see JabberWiki)

One implication of using sessions to provide a customized user experience is that logon should be automatic or strongly highlighted in the skin so that user disorientation (why is my skin/menu different from last time???) is minimized. [BTW - Note that auto-logon with certificates is fraught with client misconfiguration issues.]

-- SteveRoe - 20 Jul 2001

See Plugins.SessionPlugin. Note that latest alpha or beta post 27 Jul 2001 required.

It works as follows:

• SessionId sent as non persistant cookie to browser
• This happens in writeHeader or redirect calls
• Session file held under data/.sessions/, read on initialization
• setSessionValue and getSessionValue methods in TWiki.pm and Func.pm are used to set/get values
• When user is initialised, read from session information if present. The code in Plugins.pm is not great and assumes that the Plugin is called SessionPlugin (I wanted minimal changes because of release being soon).
• Particulary useful for skins - also enabled stickskin parameter, so that you can change the skin for a particular session.
• Session values are returned from getPrefrencesValue. They override others (TWiki, Web and user), so don't set important system values and don't expose the ability to set any value to users.

-- JohnTalintyre - 27 Jul 2001

If I use sessions, how do I log-out?

I use TWiki from public machines but I want the session to when I close the browser! If it makes a difference, I am using KoalaSkin.

Thanks...

M. -- MartinCleaver - 09 Jun 2002

A non-persistent cookie is held in the browser. So, if you close the browser, you close the session.

-- JohnTalintyre - 09 Jun 2002

I stand corrected! I had returned to the cached edit page. Thanks. M.

-- MartinCleaver - 11 Jun 2002

Why use sessions when you can use auth info? There's no reason for anyone spending much time on a wiki not to have their own identity, and authing into it will be the widest supported "session" management possible. It's no less secure than anything else. What would "sessions" add?

-- TWikiGuest - 02 Aug 2002

What do you mean by 'auth info' exactly - HTTP Authentication perhaps? If so, TWiki already uses that, and the problem is that view is not authenticated, making it hard to apply skins automatically. Many sites and packages use cookie-based authentication, e.g. Yahoo, SquirrelMail, etc.

-- RichardDonkin - 03 Aug 2002

I run a public TWiki site, and I have needs that are currently conflicting:

• Some users want to be authed so that they get credit for topics they've created and altered.
• Some users link in from other sources, want to make a quick change, and find that they can't unless they enter a username and password in the login form. After a few months of looking at server logs, I'd say that the exit page for about 95% of anonymous visitors was the one that caused them to be authed. In a nutshell, they see the login requester, hit cancel, and go elsewhere.

I want to accomodate both types of users, and the current system doesn't seem to do so. Sessions would allow people in the first category to voluntarily log in, while enabling anonymous would-be editors to make changes without getting a login prompt.

-- KirkStrauser - 13 Sep 2002

Do you have a robots.txt file to exclude search engine crawlers? Quite often they will hit a lot of Edit links and of course fail at that point.

-- RichardDonkin - 14 Sep 2002

You can put rather complex text as authorisation description. In ours, we have password for TWikiUser, so if lurker wants to contribute anonymously, s/he can.

-- PeterMasiar - 15 Sep 2002

By sessions, if Kirk is referring to removing an explicit request to login and instead users who wish to do so can then O think the combination of SessionPlugin, removal of password control on scripts such as edit and an auth protected script like logon that comes with SessionPlugin should to the trick.

-- JohnTalintyre - 16 Sep 2002

Richard, yes, I use a robots.txt file. The clients in question are typically Mozilla or MSIE, and their first page is often one that I've just mentioned in a public forum. That is, I'm almost certain that they're real, human visitors.

Peter, while I understand what you mean, I think that many people hit cancel as soon as they see a login dialog. Of course, you could argue that those aren't the people that I want making updates to the technical content on my site, but I'm not quite ready to make that jump.

John, you are absolutely correct. I've been having some strange and not-always-reproducible problems with SessionPlugin, though, and really hope that session support becomes part of the main codebase.

-- KirkStrauser - 17 Sep 2002

There are always a significant minority who are highly anti cookies (as used to support the sessions), hence having this as a standard part of the main codebase has been deliberately avoided. In any case, please report specific problems with SessionPlugin at SessionPluginDev, as fixing here is no different to fixing in the core. I should add that the Plugin API specifically had calls added so that SessionPlugin would work i.e. there is the required level of support in the core.

-- JohnTalintyre - 17 Sep 2002