[xwiki-devs] [Proposal] Stop tracking sessions in URL (when cookies are off)
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? Here's my +1 Thanks -Vincent
I forgot to mention that if you google you'll find several articles about dropping jsessionid in URLs. For example: http://java.dzone.com/articles/java-jsessionid-harmful Thanks -Vincent On Fri, Nov 15, 2013 at 9:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent
+1 to drop jsessionid use On Fri, Nov 15, 2013 at 9:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 for not supporting insane requirements :) Thanks, Caleb On 11/15/2013 09: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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Isn't there a servlet container configuration to disable jsessionid? Thanks, Marius On Fri, Nov 15, 2013 at 10:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Nov 15, 2013 at 9:58 AM, Marius Dumitru Florea < [email protected]> wrote:
+1
Isn't there a servlet container configuration to disable jsessionid?
Yes there is but we don't control that, the user would need to setup his container and you can be sure he'll forget to do it, thus causing lots of bugs/issues on the XWiki side ;) Thanks -Vincent
Thanks, Marius
On Fri, Nov 15, 2013 at 10:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1! It's a bad from the security POV. 2013/11/15 Vincent Massol <[email protected]>
On Fri, Nov 15, 2013 at 9:58 AM, Marius Dumitru Florea < [email protected]> wrote:
+1
Isn't there a servlet container configuration to disable jsessionid?
Yes there is but we don't control that, the user would need to setup his container and you can be sure he'll forget to do it, thus causing lots of bugs/issues on the XWiki side ;)
Thanks -Vincent
Thanks, Marius
On Fri, Nov 15, 2013 at 10:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1, if you block cookies you may expect 99% of sites to be broken anyway, far better to break those not using cookie than to got issues with our features. On Fri, Nov 15, 2013 at 10:30 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
+1! It's a bad from the security POV.
2013/11/15 Vincent Massol <[email protected]>
On Fri, Nov 15, 2013 at 9:58 AM, Marius Dumitru Florea < [email protected]> wrote:
+1
Isn't there a servlet container configuration to disable jsessionid?
Yes there is but we don't control that, the user would need to setup his container and you can be sure he'll forget to do it, thus causing lots of bugs/issues on the XWiki side ;)
Thanks -Vincent
Thanks, Marius
On Fri, Nov 15, 2013 at 10:48 AM, Vincent Massol <[email protected]> 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?
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
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
participants (7)
-
Caleb James DeLisle -
Denis Gervalle -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol