users@grizzly.java.net

Re: JSON data as cookie value

From: Johan Maasing <johan_at_zoom.nu>
Date: Fri, 22 May 2015 19:46:19 +0200

+1 for that change.

2015-05-22 18:16 GMT+02:00 Marc Arens <marc.arens_at_open-xchange.com>:

> Hey Alexey,
>
> my current approach looks like this
>
> https://github.com/dermarens/grizzly-mirror/commit/bcc9184451fe55576c088b688c82489090fc81f2
> No idea if a github pull request would be useful to you as you use github
> as
> readonly mirror AFAIU.
>
> > On 22 May 2015 at 01:48 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
> wrote:
> >
> >
> > Hey,
> >
> >
> > > i'm not really keen on supporting JSON data. IMHO Clients should
> > > properly encode the data, yet Grizzly has to behave more defensively.
> > > I was thinking about at least catching the IllegalArgumentException
> > > when constructing javax.servlet.http.Cookies. I'll probably create a
> > > patch anyway when i'm back at work tomorrow.
> > >
> > > A config parameter to toggle the behaviour might be an option but it
> > > might enable things like
> > > https://www.owasp.org/index.php/HTTP_Response_Splitting or other
> attacks.
> > >
> > Oh, I misunderstood your intention, I though you wanted Grizzly to
> > accept such a JSON cookie.
> > In general, if people want this "feature" to be supported - we can do
> > that, but definitely not as default behavior.
> >
> > Thanks!
> >
> > WBR,
> > Alexey.
> >
> > >> On 21 May 2015 at 23:39 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
> > >> wrote:
> > >>
> > >> Hi Marc,
> > >>
> > >> IMO we can keep current implementation as a default, but at the same
> > >> time we can introduce a config parameter to be able to support json
> > >> cookies.
> > >>
> > >> WDYT?
> > >>
> > >> WBR,
> > >> Alexey.
> > >>
> > >>
> > >> On 21.05.15 14:09, Marc Arens wrote:
> > >>>
> > >>> Moin,
> > >>>
> > >>> web developers seem to get creative these days and start storing
> > >>> unencoded/stringified JSON data in cookies (see [1] for examples).
> > >>> As commas are forbidden as part of the cookie value per rfc 6265 [2]
> > >>> AFAIU
> > >>>
> > >>> cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
> > >>> cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
> > >>> ; US-ASCII characters excluding CTLs,
> > >>> ; whitespace DQUOTE, comma, semicolon,
> > >>> ; and backslash
> > >>>
> > >>> this of course causes problems when these cookies reach the grizzly
> > >>> server as part of a normal request. Grizzly versions from 2.2 to 2.3
> > >>> split the cookie values after the ',' which might cause further
> > >>> exceptions and break the complete request.
> > >>>
> > >>> e.g.
> > >>>
> > >>>
> > >>> issue a request like: curl -v --cookie
> > >>> "name={\"id\":\"5070419\",\"Version\":\"undefined\"}"
> > >>>
> > >>> Grizzly now turns the JSON into two cookies
> > >>>
> > >>> Cookie1:
> > >>> Name: name
> > >>> Value: {"id":"5070419"
> > >>>
> > >>>
> > >>> Cookie2:
> > >>> Name: Version
> > >>> Value:
> > >>>
> > >>> If you are now using Servlets within Grizzly this will fail with an
> > >>> IllegalStateException while trying to create Cookies
> > >>>
> > >>> Caused by: java.lang.IllegalArgumentException: Cookie name "Version"
> > >>> is a reserved token
> > >>> at javax.servlet.http.Cookie.<init>(Cookie.java:150)
> > >>> at
> > >>>
> org.glassfish.grizzly.servlet.HttpServletRequestImpl.getCookies(HttpServletRequestImpl.java:1127)
> > >>>
> > >>>
> > >>> I compared Grizzly's cookie parsing to Jetty and while Jetty 7 fails
> > >>> in a slightly different way
> > >>>
> > >>> Cookie1:
> > >>> Name: name
> > >>> Value: {"id":"5070419"
> > >>>
> > >>>
> > >>> Cookie2:
> > >>> Name: Version
> > >>> Value:
> > >>>
> > >>> Jetty 9 seems to parse the cookie "correctly"
> > >>>
> > >>> Cookie1:
> > >>> Name: name
> > >>> Value: {"id":"5070419","Version":"undefined"}
> > >>>
> > >>>
> > >>> So my question is: Should Grizzly's cookie parsing be adjusted to
> > >>> behave more like Jetty although the RFC is pretty clear on this
> > >>> topic? What's your opinion on this? Maybe dropping malformed cookies
> > >>> while logging an error to simply defend against bad behaviour would
> > >>> be the way to go?
> > >>>
> > >>>
> > >>> [1] https://github.com/carhartl/jquery-cookie
> > >>>
> > >>> [2] http://tools.ietf.org/html/rfc6265#section-4.1.1
> > >>>
> > >>>
> > >>> ...it was evening and it was morning and there were already two ways
> > >>> to store Unicode...
> > >>>
> > >>
> > >
> > > ...it was evening and it was morning and there were already two ways
> > > to store Unicode...
> > >
> >
>
> ...it was evening and it was morning and there were already two ways to
> store
> Unicode...
>