Feature Proposal: Make cookie paths, session cookie name configurable

Motivation

Over in Tasks.Item1636 those of us running multi-homed Foswiki installations (I.E. http & https) are struggling because each vhost must re-use the same FOSWIKISID cookie name.

Problem: a user authenticates over https and FOSWIKISID is set. Then, the user accesses the site over http (accidentally, or they followed a link). Foswiki doesn't see any FOSWIKISID in the http request because the browser doesn't send it (has the secure flag set).

Foswiki issues a new session and FOSWIKISID value, so the user now loses their old session for a new one obtained under http; if they go back to https, they've now got a different FOSWIKISID - they must also re-auth the new session.

Description and Documentation

While we're at it, as with ExpertOptionForCookieDomainRealm, add expert options to:

• Make the cookie path configurable. "best practice" especially on domains with multiple/shared foswiki installations should set the scope of their cookie to a more constrained path than '/'.
• Allow a configurable prefix for the FOSWIKISID and perhaps other names. This probably means we need an API to build cookie names (Eg. FOSWIKISID, FOSWIKIPREF, etc).
• Prefix cookie names with an 'S_' if accessing over SSL and the secure flag is set. This allows an out-of-the-box Foswiki installation to function properly if it is served over both http & https simultaneously.

Examples

• Add a $Foswiki::cfg{Session}{CookiePath} which defaults to '/'. Configure checker to issue a warning if you've got a non-root {ScriptUrlPath} and this is left as '/'.
• Add a $Foswiki::cfg{Session}{CookieNamePrefix} which defaults to the empty string ''.
• Something like

  my $cookiename = Foswiki::Func::getCookieName('FOSWIKISID');

  should result in:

Name	HTTPS	CookieNamePrefix	Result
FOSWIKISID	0		FOSWIKISID
FOSWIKISID	1		SFOSWIKISID
FOSWIKISID	0	FOO	FOOFOSWIKISID
FOSWIKISID	1	FOO	FOOSFOSWIKISID

• Review FOSWIKIPREF, etc. and javascript access to cookies nu name

Impact

Implementation

-- Contributors: PaulHarvey - 30 Mar 2011

Discussion

-- PaulHarvey - 30 Mar 2011

See also: BlurAuthCookieName

-- PaulHarvey - 17 Dec 2011

The change to add S prefix for https cookies: Is that going to break all current sessions for sites already running on https? And also leave stale cookies in everyone's browsers?

I think it would be good to get this merged into 1.1.5. At least the pieces that are not going to require significant API changes.

-- GeorgeClark - 17 Feb 2012