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

WhatDoesItAffect:

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

Deferred to 2.0 as there hasn't been actions for 1.2 anymore.

-- MichaelDaum - 02 Jun 2014

Changing to Parked, Needs developer to adopt.

-- GeorgeClark - 19 Nov 2015

Looks like we need to reactivate this one ASAP, as trunk.foswiki.org is not reachable once logged on to foswiki.org

The problem is that we've changed foswiki.org to $Foswiki::cfg{Sessions}{CookieRealm} = 'foswiki.org'; This results in the actual cookie:

Name   SFOSWIKISID
Value   aaaaaaaa
Host   .foswiki.org
Path   /
Expires   At end of session
Secure   Yes
HttpOnly   Yes

When you log into trunk.foswiki.org, it also sets a cookie:

Name   SFOSWIKISID
Value   bbbbbbbb
Host   trunk.foswiki.org
Path   /
Expires   At end of session
Secure   Yes
HttpOnly   Yes

Firefox (and Chrome) seem to match the wildcard SFOSWIKISID cookie rather than the trunk.foswiki.org cookie, and the user cannot get past the login screen. Clear the cookies, login to trunk and it works fine. Login to foswiki.org, and trunk then flips back to a login screen on the next access.

For the implementation, In addition to the Cookie Name prefix for the Session cookie. It needs to be propagated to all the server side, and javascript set cooikes. So it means adding the path and prefix to the foswiki prefs hash.

-- GeorgeClark - 24 Jan 2017

Initial implementation in Item14301 branch.

-- GeorgeClark - 24 Jan 2017

Due to inconsistencies in how we create & read cookies in javascript, getting name prefix, path and secure flags set consistently is difficult. MichaelDaum pointed out that we should upgrade our cookie JS code to https://github.com/js-cookie/js-cookie/tree/latest

Checking JQueryCookie hosted upstream at https://github.com/carhartl/jquery-cookie. This lib needs to be replaced by https://github.com/js-cookie/js-cookie. Not a task for this bug item. Just mentioning as I checked the code.

-- GeorgeClark - 31 Jan 2017

Noticed an issue, strikeone cookie "FOSWIKISTRIKEONE" will be written as "Secure" when visited using https. But for a site that supports both, when switching back to http:, then strikeone no longer works. Need to use SFOSWIKISTRIKEONE like we do with SFOSWIKISID.

-- GeorgeClark - 22 Mar 2017

Commenting is disabled while not logged in