Cookie isssues and possible bugs

[Mohammad Bhuyan]

(1) Cookie expiry

I found out that after setting max age to 0, the cookie was not expiring. I figured out that expiry the time you were sending back as GMT was right. Finally, I found out that the date format is not in accordance with the RFC. 

RFC 6265 (Section 4.1.1) dictates:

expires-av        = "Expires=" sane-cookie-date

sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1>

In RFC 2616:

HTTP-date    = rfc1123-date | rfc850-date | asctime-date

rfc1123-date = wkday "," SP date1 SP time SP "GMT"

date1        = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) 

Whereas you are doing 

date2        = 2DIGIT "-" month "-" 2DIGIT

Which is meant to be for, rfc850-date  = weekday "," SP date2 SP time SP "GMT" 

 

Having said that, I can see firefox accepts your date format ( date2 ) when creating a cookie. Firebug shows the expiry date properly, which means the browser must have accepted it! 

(2) Multiple cookie

In a page, I do a AJAX call (using jQuery) that responds back with a cookie as following:

val cookie = new DefaultCookie(...);
cookie.setPath("/");
cookie.setHttpOnly(true);
cookie.setMaxAge(365*24*60*60);

This goes right, ad the cookie is set. But in the handler of my AJAX, in client side, you may proceed to a new page (GET).
When this redirect happens, the browser sends the cookie (that it had just received from AJAX POST) in the GET request.
Xitrum, in its GET response sends the cookie back again, thus causing a cookie to be set in a new path.

Lets look at the following example:

(a) AJAX POST

Request Headers:

Accept application/json, text/javascript, */*; q=0.01

Accept-Encoding gzip, deflate

Accept-Language en-US,en;q=0.5

Cache-Control no-cache

Connection keep-alive

Content-Length 45

Content-Type application/x-www-form-urlencoded; charset=UTF-8

Cookie __utma=111872281.2014361753.1354591167.1354591167.1354591167.1; __utmb=111872281.1.10.1354591167; __utmc=111872281; __utmz=111872281.1354591167.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Host localhost:4430

Origin http://localhost:8000

Pragma no-cache

Referer http://localhost:8000/concenter/welcome/

User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Firefox/17.0

Response Headers:

Access-Control-Allow-Cred... true

Access-Control-Allow-Orig... http://localhost:8000

Cache-Control no-store, no-cache, must-revalidate, max-age=0

Connection keep-alive

Content-Length 33

Content-Type application/json; charset=UTF-8

Etag "jcqUwe0bwhJasnbZ5f_JhQ"

Set-Cookie __utma=111872281.2014361753.1354591167.1354591167.1354591167.1 __utmb=111872281.1.10.1354591167 __utmc=111872281 __utmz="111872281.1354591167.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" concenter_session="x@b.c"; Expires=Wed, 4-Dec-13 03:19:36 GMT; Path=/; HTTPOnly

Resultant Cookie:

Name: concenter_session

Value: "x@b.c"

Domain: localhost

Size: 24 B

Path: /

Expires: Wed 4 Dec 14:19:36 2013

HttpOnly: HttpOnly

(b) Following GET

Request Headers:

Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Encoding gzip, deflate

Accept-Language en-US,en;q=0.5

Connection keep-alive

Cookie __utma=111872281.2014361753.1354591167.1354591167.1354591167.1; __utmb=111872281.1.10.1354591167; __utmc=111872281; __utmz=111872281.1354591167.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); concenter_session="x@b.c"

Host localhost:4430

Referer http://localhost:8000/concenter/welcome/

User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Firefox/17.0

Response Headers:

Connection keep-alive

Content-Length 18

Content-Type text/html; charset=UTF-8

Etag "wG-bYMJvTt2w6Zie2oQJlw"

Set-Cookie __utma=111872281.2014361753.1354591167.1354591167.1354591167.1 __utmb=111872281.1.10.1354591167 __utmc=111872281 __utmz="111872281.1354591167.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" concenter_session="x@b.c"

Resultant Cookies:

 

Name: concenter_session

Value: "x@b.c"

Domain: localhost

Size: 24 B

Path: /

Expires: Wed 4 Dec 14:19:36 2013

HttpOnly: HttpOnly

Name: concenter_session

Value: "x@b.c"

Domain: localhost

Size: 24 B

Path: /concenter/sites/

Expires: Session

I hope this helps, Regards

[Ngoc Dao]

Thanks for the investigation.

I've just fixed the multiple session cookies problem by fixing the
path of the session cookie:
https://github.com/ngocdaothanh/xitrum/commit/e1ea35bf0a69bd4cc7010794b213584647aeecc8

Please use the 1.9.11-SNAPSHOT version:
git clone git://github.com/ngocdaothanh/xitrum.git
cd xitrum
sbt/sbt publish-local

Then in your project's build.sbt, use:
libraryDependencies += "tv.cntt" %% "xitrum" % "1.9.11-SNAPSHOT"

[Mohammad Bhuyan]

Thanks, I will come back with update.

[Mohammad Bhuyan]

Hi Ngoc,

As you have mentioned, session cookies are now NOT in multiple. I have tested any one of my problem is gone.

But the problem I reported in this thread, If I programatically set a cookie, in this case, I am setting a cookie named "concenter_session" (not to be confused with Xitrum session cookie) and it is being set twice for the same reason as session cookie.

I have see your git log and seems like you have doesn a special case when the cookie is Xitrum "session" cookie. What about my case when when I am creating my own cookie in Actions.

Regards,
Mohammad

[Ngoc Dao]

> If I programatically set a
> cookie, in this case, I am setting a cookie named "concenter_session" (not
> to be confused with Xitrum session cookie) and it is being set twice for
> the same reason as session cookie.

You need to set path for your cookie.

I've just improved the Xitrum guide:
https://github.com/ngocdaothanh/xitrum-doc/commit/f72d4a6dba48f3fdea14821c90c8bd177b7c3f3a
https://github.com/ngocdaothanh/xitrum-doc/blob/master/guide/scopes.rst#cookie

[Ngoc Dao]

More info:
http://stackoverflow.com/questions/4056306/how-to-handle-multiple-cookies-with-the-same-name

[Mohammad Bhuyan]

Hi Ngoc,

Apologies for being sticky on this. But if you read carefully my original investigation, I had set path for my cookie. The path is "/". I have now tired xitrum.Config.withBaseUrl("/") which in my case is "/". Still multiple cookie.

This is what happens.

(1) A POST send back the following cookies. Where "concenter_session", lets say, is my "Remember me" cookie. This is a work in progress, In reality I will not have the email exposed. I have set path to "/" and a year validity. Everyhting is OK.

_session=AAAAMPrmg96U65-dSyXQc7-zOCyU4jDh3A2B0iL0C1bxYn-_m6ZZcZgiPkVqq3IFnYYC7YxcAwJjlPhX2o-jJ1kiGGEnodtv-m7C6nmDJ_NRgHP2; Path=/; HTTPOnly 

concenter_session="b@c.d"; Expires=Wed, 4-Dec-13 13:58:56 GMT; Path=/; HTTPOnly

(2) A GET then sends back the cookie with request.

_session=AAAAMPrmg96U65-dSyXQc7-zOCyU4jDh3A2B0iL0C1bxYn-_m6ZZcZgiPkVqq3IFnYYC7YxcAwJjlPhX2o-jJ1kiGGEnodtv-m7C6nmDJ_NRgHP2; concenter_session="b@c.d"

(3) In response you send the cookie back (even though it was not modified in any way) .

_session=AAAAMPrmg96U65-dSyXQc7-zOCyU4jDh3A2B0iL0C1bxYn-_m6ZZcZgiPkVqq3IFnYYC7YxcAwJjlPhX2o-jJ1kiGGEnodtv-m7C6nmDJ_NRgHP2; Path=/; HTTPOnly 

concenter_session="b@c.d"

BUT since the browser didn't send any details of the cookie, it the process of sending it back, it is resulting in a new cookie with a path (base url of the GET resource) as derived by the browser. Also no expiry date makes it session. etc etc. My original cookie gave birth to a new cookie.

Why do you need to send back the Cookie that I have not modified it?

Or am I missing standard/best practice knowledge about using cookie?

Regards,

Mohammad


On Tuesday, December 4, 2012 9:08:38 PM UTC+11, Ngoc Dao wrote:

More info:
http://stackoverflow.com/questions/4056306/how-to-handle-multiple-cookies-with-the-same-name

[Mohammad Bhuyan]

Btw, thanks for the quick response on the session issue. 

[Ngoc Dao]

> *BUT since the browser didn't send any details of the cookie, it the

> process of sending it back, it is resulting in a new cookie with a path
> (base url of the GET resource) as derived by the browser. Also no expiry
> date makes it session. etc etc. My original cookie gave birth to a new
> cookie.

> *Why do you need to send back the Cookie that I have not modified it?

> Or am I missing standard/best practice knowledge about using cookie?

You're right. "Browsers will not send cookie attributes back to the
server. They will only send the cookie’s name-value pair."
http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes

I will change the cookie API of Xitrum to requestCookies and
responseCookies. Only cookies in responseCookies will be send to
browsers. If you don't set anything, no cookies will be send to
browser.

[Mohammad Bhuyan]

Fantastic, Ngoc. I am eagerly waiting for the update.

You will be glad to know that I have just figured out that the cookie expiry is working as advertised, there is no bug fault in the code. The double cookie issue was masquerading the expired cookie. I will confirm again after I have received the update.

Btw, I am sure it will not escape your mind that, you will need to do your "automagic" to include the Xitrum session cookie in the responseCookies whenever it is changed or generated.    

Regards,

Mohammad

[Ngoc Dao]

Thanks Mohammad.

I've implemented requestCookies and responseCookies. Updated doc:
https://github.com/ngocdaothanh/xitrum-doc/blob/master/guide/scopes.rst#cookie

If there's no problem, I will officially publish 1.9.11 today.

Please try the latest 1.9.11-SNAPSHOT version:

[Ngoc Dao]

> In reality I will not have the email exposed

FYI, if you want to sign your cookie value to prevent user from
tampering (and seeing its value), use
xitrum.util.SecureBase64.encrypt:
http://ngocdaothanh.github.com/xitrum/guide/howto.html#encrypt-data

If the value is somewhat big, pass "true" to the 2nd param of
SecureBase64.encrypt. Xitrum will try to GZIP compress if the cookie
value exceeds 4KB.

[Mohammad Bhuyan]

Reported issues are resolved with v1.10. Thanks.