On 11/15/2013 03:48 AM, Vincent Massol wrote:
Hi devs,
Right now we're trying to support clients (browsers namely) that have
cookies turned off.
I've recently updated code to try to support that but I've found that:
1) It's very hard and we still have lot of places in our code that doesn't
work without cookies
2) It adds ;jsessionid in the URL and this is causing havoc in tons of
unsuspecting place such as RSS feed generation (RSS readers get different
URLs every time thus thinking it's a different article, exports,
watchlist, tests, etc).
3) It's a security risk to expse the sessionid in the URL
4) It's bad for SEO since search bots may index several times the same
resource with different sessionid (it's a new one every time)
5) There are lots of cases where we don't need to track sessions (like for
RSS feed generation or HTML exports)
I started fixing all failing places because of the ;jsessionid in the URL
but more keep coming and it feels strange to have to remove it a bit
everywhere when we're adding it in our URL factory.
Thus I'd like to propose that we officially don't support tracking sessions
in URLs (i.e. when browsers have cookies turned off).
The idea is that I'd still call encodeURL in our XWikiURLFactory
implementations (we need this if we want to support URL rewriting for short
URLs for example) but XWikiURLFactory would strip any jsessionid from the
URL.
WDYT?
+1.
Ideally, a public site that wants to be accessible should work without
cookies and without JavaScript. However, more and more sites (and the
frameworks they're built on) rely on both, so the general expectation is
to have JS and cookies enabled. The fact that others do it is not a good
enough reason for us to follow suite.
On the other hand, cookies are only required for those that explicitly
want to interact with the wiki by logging in. That is explicit consent
to accept the requirements of the site, including cookies, so any
privacy conscious internet user should be willing to accept XWiki's
cookies. And it's not like we're a big advertising evil company tracking
unaware users for profit.
And then I find path parameters dangerous for security, ugly, and hard
to work around. Containers should transparently strip them from any URL
reaching the actual Java code.
--
Sergiu Dumitriu
http://purl.org/net/sergiu