Item140: session oddness for multiple hostnames

If i log into http://nextwiki.org, I'm not logged in on http://www.nextwiki.org

really non dwim.

-- SvenDowideit - 11 Nov 2008 - 11:21

Comments

Note for SEO purposes, it is preferable to redirect all synonymous URLs to the corresponding canonical one, which eliminates the issue of host-specific cookies.

Cookies can be specified with a domain instead of a full hostname (so they will be sent to all hosts in the domain), but this would not help when the synonymous URL is in a different domain, and could also cause problems with multiple Foswiki installations within a domain.

-- IsaacLin

agreed - for public sites. I have observed this issue at client sites, where there may be several valid names that they want to continue using. I'm wondering (and will probly investigate) why the session value is different - I'm not entirely convinced that there is a utility in it.

-- SvenDowideit

Even in an intranet environment, having multiple URLs for a site could dilute the search results in an intranet search engine. I can't think of many good reasons to not redirect -- perhaps the company has an SSL certificate for site A but not B, and so it wants links to A to continue to work without redirection? But in a corporate environment, typically self-signed certificates are good enough.

-- IsaacLin - 12 Nov 2008 - 04:05

I can't see a good reason to impose arbitary limitation on a usergroup - I have had instances where useage groups want to use different URL's, and quite honestly, its not up to me to tell them they are wrong.

IMO, if we can find a way to reduce un-necessary limitations on funtionality, without compromising the other variables, there is no excuse not to do so (and I think we can do better than we are atm - though i've not yet found time to poke the code in this area)

-- SvenDowideit

Both ways impose limitations -- if you use a cookie that specifies a domain instead of a host, for example, you may limit the ability to deploy multiple Wiki installations in the domain. Given that there is a reasonable alternate approach, the case of completely different domains cannot be resolved simply, and the best solution is probably a single-sign on approach (say, to OpenID or other similar provider on the Internet, and to whatever corporate system is being used in a given intranet), I believe this item should be be given lower priority.

-- IsaacLin - 13 Nov 2008 - 06:25

ah, you're presupposing a particular solution - and one that would not be a good one. I'm contemplating that there is another.

-- SvenDowideit - 13 Nov 2008 - 12:29

Not at all -- it's just that the consequences may be different for another implementation, so I chose one specific implementation so I could give a concrete example of the tradeoff. Any solution will have to either transfer the user's identity information or session identification to the server in both sites in some matter. For security purposes, the web is designed to avoid having one site establish information to be communicated with another, so working around this design invariably requires some limitations in functionality or server deployment.

-- IsaacLin - 13 Nov 2008 - 23:47

mmmm, You're implying (via the transfer identity phrase) that there needs to be communication between 'sites', when what I'm looking at, is the situation where there are several valid Names for a single site. Still, I'm struggling to see how what you're telling me is helping - I'm looking at a known usability issue, to which I suspect I can figure out an improvement, while you're telling me there is no improvement possible, because the 'ideal' solution is impossible.

you do however point out an interesting risk we have with the session cookies - that the 12 Wiki's I have installed on my one server have no definite way to validate that a cookie is their's, and not one of the other Wiki's - which seems to me to lead towards a solution to this issue too.

-- SvenDowideit - 14 Nov 2008 - 00:29

No, not direct communication between sites, but a user's identity or the user's session must be associated with accesses to both sites. This means something must be communicated from the user's browser to both sites (and to the same underlying server) which the server can connect together (typically a session or identity token of some sort). For security purposes it must be time-limited, and so it is set up at the start of a session when logging in. If the user is expecting to access the same server through another site address, something related to this established token must be transmitted to the second site. The server must then be able to connect up this something with the previously established token.

As for what I am suggesting -- see my comment on November 13. Almost anything can be improved in some way, of course, but the relative benefit may not be proportionate to the effort, and other avenues may be more fruitful to pursue. For example, with a single sign-on solution, both sites redirect to a common site to perform the authentication and setup the required token, so any one site can set up the token for use by others. (Of course, your own needs for your consulting work may result in a different evaluation of the relative benefit.)

Cookies include path information which can serve to distinguish between multiple installations on one host.

-- IsaacLin - 14 Nov 2008 - 00:55

Cookies include path information, um, no, they can include path information, but if you look at the cookies that TWiki sends, (at least the ones I just looked at), it doesn't. And clearly, I am not agreeing with your assessment that there is no change we can make to the current implementation that is not worth doing.

-- SvenDowideit - 14 Nov 2008 - 05:23

I apologize for the confusion; I did not mean to imply that Foswiki's cookies include path information. I was only providing a suggestion for how a distinction could be made between multiple installation.

-- IsaacLin - 14 Nov 2008 - 05:26

From reading the above I believe this problem is Confirmed, so changing status to reflect that.

-- CrawfordCurrie - 04 Jan 2009

In 1.1, the cookie realm can be configured: {Sessions}{CookieRealm} Setting it to .foo.com would should allow www.foo.com to read/set the cookie. Does that partially resolve this item?

-- GeorgeClark - 22 Aug 2010

Additionally, it would be useful to set the path, to avoid leaking cookies to other sites on the same host/domain. Although IIRC there was a bug in IE6 (or was it 5.x?) that meant you had to set a cookie path one level higher than desired or it would block cookies needlessly.

-- PaulHarvey - 23 Aug 2010

Sven, no feedback since August, and I suspect setting the Cookie realm does resolve the issue. Setting to No Action. I've confirmed here that setting cookie realm to "blah.com" allows one to log in to wiki.blah.com and still be logged in on foswiki.blah.com - at least with template auth.

-- GeorgeClark - 15 Mar 2011