get_cookie returning None?

[Nick Jennings]

Hi All,

I'm wondering if tornado has some special conditions when attempting
to retrieve a cookie. The thing is, the cookie is set by another app,
and I need to grab it with tornado.

The cookie name is "myapp_session" and contains an encrypted string
which decrypts to key/value fields.

I tried self.get_cookie like this:


@tornado.web.asynchronous
@tornado.gen.engine
def on_message(self, message):
cookie = self.get_cookie('myapp_session')
logging.info('COOKIE: %s' % cookie)

That gets 'None'.. .I've checked the browser, and that cookie is
definitely there. Is there something I'm missing?


Thanks
Nick

[Russ Weeks]

Hi, Nick,

You say you've checked that the cookie exists in the browser, but did you check that it's submitted as part of the HTTP request that tornado processes?  The same-origin policy for cookies is a little convoluted  (eg. if the cookie was set by login.example.com, it might not be submitted to www.example.com), or if the cookie was originally flagged as "secure" it won't be submitted over an HTTP connection.

You can inspect the HTTP request with the Chrome developer tools, Firebug or Wireshark.

Regards,

-Russ

[Nick Jennings]

Hi Russ,

Thanks for your reply.

The Tornado socket is running on the same sub-domain as the main app.
So it shouldn't be a domain issue.

How can I check the tornado header info to see if the cookie is being
sent along?

Here's what the chrome tools say about the cookie. I can't see
anything that would indicate why it's not able to grab it.


Name: myapp_session
Content: hih0PR921266eUgJ5nNQ9WPEtg7mIvPwA0fM%2B1JCNIP0FqysGCt4X40X9NtevWs1naJbPqzzGNyjgVGWPY4p1oS4XqhSHe1qsvIir%2BlkKIEd21CQUcBepCvlJEl4bpgO7%2Fv4BkP0ajvgJ%2F1XLpXbUCREMp7PGn1wo8MGImiBctmQIEzmFA5nFDtTH9nj0WL6Ino1umT%2F089YlkcNq0cWF72ds3fbPYD%2Bzuivfze0M61DeGKteS6ZaMl3zdLXFG9e52FiYAVGiid5%2FmasXrJdH3fJZP4xlagYVkUG2NeMAcjfBGPOBdy8N5eIPVXmb24G4NCvpdPcdYbxe3SGdUCzGLWEdyWmUXZbegi8qZSFhod5VV46yyQhCTsWR81nKuuTLOCZ1bVTVOAUeeuU8TtK6%2BStdO0qiTEDJy6Ct4DlkZEF%2Fwex6g%2B9LuSktYYMvlrIVODLJ0L4eqdzAML1xMIOHRGBZEvpeL4JjrhVrCeg9h55k2Q39hat1d0koAyVuAg2GTvprllzyaFZxNhRt1t3tegCvBQPfvVtBewW3ed%2B1A0cCDlEW%2BHBiuDL6wS3mwsZRCOwNy0xZZqJTgOt9N8ORQMg92udj3
Domain: demo.myapp.com
Path: /
Send For: Any kind of connection
Accessible to Script: Yes
Created: Saturday, August 25, 2012 1:12:11 PM
Expires: Monday, August 25, 2014 1:12:12 PM

[Nick Jennings]

I've verified that, from outside tornado, I can retrieve the cookie
string using os.environ['HTTP_COOKIE'] and the particular cookie I
need is in the string.

So it's definitely a tornado issue.

Any ideas as to how I can even begin to debug this? At which point
should the HTTP header data be exposed to the listener? I've tried
os.environ['HTTP_COOKIE'] in: init, initialize, open, and on_message -
the key never exists.

I've tried get_cookie(<name>) and it always returns None.




On Sat, Aug 25, 2012 at 1:39 PM, Nick Jennings

[Ben Darnell]

Environment variables like $HTTP_COOKIE are a CGI concept, but Tornado
does not run in a CGI environment (well, you could run it in WSGI mode
under CGI, but then you wouldn't be able to use any of the async
features). What does your serving stack look like? You need to use
some sort of proxy to make tornado and the other service available on
the same port (both the domain and port must match for the cookies to
be sent). The most reliable way to see what is being sent to tornado
is to either add logging to tornado's httpserver or use tcpdump or
wireshark.

-Ben

[Russ Weeks]

Hi, Nick,

How can I check the tornado header info to see if the cookie is being
sent along?

In the Chrome developer tools, you can see the HTTP requests in the "Network" tab.  For each request, you can see the headers in the "Request Headers" section of the headers tab.  You should see an entry called "Cookie" showing the myapp_session cookie.

If you want to see the lower-level details of how Tornado is parsing the HTTP request, I think you should look at either request.headers or maybe request.connection.stream.read_buffer?  But this code is pretty robust; I would make doubly-sure that the cookies are getting sent across the wire first.

Regards,

-Russ

[Nick Jennings]

Hi Ben, thanks for your reply, response below:

On Sat, Aug 25, 2012 at 9:12 PM, Ben Darnell <b...@bendarnell.com> wrote:
> Environment variables like $HTTP_COOKIE are a CGI concept, but Tornado
> does not run in a CGI environment (well, you could run it in WSGI mode
> under CGI, but then you wouldn't be able to use any of the async
> features).

Yes, I was just doing that as a test to make sure the cookies were
available on the domain from somewhere outside the originating app
(which is a PHP app).

> What does your serving stack look like? You need to use
> some sort of proxy to make tornado and the other service available on
> the same port (both the domain and port must match for the cookies to
> be sent).

The main PHP app runs at demo.myapp.com via. Apache and issues the
authenticating cookie. The tornado server runs at demo.myapp.com:8002
(it's in testing phase so we don't use any proxying yet).

So, from the WebSocketHandler, no cookie data can be found.

> The most reliable way to see what is being sent to tornado
> is to either add logging to tornado's httpserver or use tcpdump or
> wireshark.

Can you tell me at which point the HTTP headers are sent to tornado?


Thanks,
Nick

[Nick Jennings]

Hi Russ,

On Sat, Aug 25, 2012 at 9:14 PM, Russ Weeks <rwe...@newbrightidea.com> wrote:
>> How can I check the tornado header info to see if the cookie is being
>> sent along?
>
> In the Chrome developer tools, you can see the HTTP requests in the
> "Network" tab. For each request, you can see the headers in the "Request
> Headers" section of the headers tab. You should see an entry called
> "Cookie" showing the myapp_session cookie.

Yes, I've already verified this - my question was regarding the
server-end of things. How can I get a dump of the HTTP headers that
Tornado receives so I can see if the cookie data is even being sent or
not. Because I know it's in the browser, and I know that when I test
on the same domain, with a python cgi script (apache), the cookie data
is all there as expected. So, it's just Tornado that can't find it.

> If you want to see the lower-level details of how Tornado is parsing the
> HTTP request, I think you should look at either request.headers or maybe
> request.connection.stream.read_buffer? But this code is pretty robust; I
> would make doubly-sure that the cookies are getting sent across the wire
> first.

Well, request.headers.get_cookie('cookiename') returns None. Which
library/method do the HTTP headers come in on?

Thanks,
Nick

[Ben Darnell]

On Sat, Aug 25, 2012 at 12:27 PM, Nick Jennings
<nick.sil...@gmail.com> wrote:
> The main PHP app runs at demo.myapp.com via. Apache and issues the
> authenticating cookie. The tornado server runs at demo.myapp.com:8002
> (it's in testing phase so we don't use any proxying yet).

That's your problem then. demo.myapp.com and demo.myapp.com:8002 are
considered different domains for the purposes of cookies. You need to
set up a proxy to get them both on the same port for this to work.

>
> So, from the WebSocketHandler, no cookie data can be found.
>
>
>> The most reliable way to see what is being sent to tornado
>> is to either add logging to tornado's httpserver or use tcpdump or
>> wireshark.
>
> Can you tell me at which point the HTTP headers are sent to tornado?

Tornado reads them from the network when the browser makes a request.
See HTTPServer._on_headers. tcpdump will let you non-invasively
eavesdrop on the connection.

-Ben

[Nick Jennings]

On Sat, Aug 25, 2012 at 9:32 PM, Ben Darnell <b...@bendarnell.com> wrote:
> On Sat, Aug 25, 2012 at 12:27 PM, Nick Jennings
> <nick.sil...@gmail.com> wrote:
>> The main PHP app runs at demo.myapp.com via. Apache and issues the
>> authenticating cookie. The tornado server runs at demo.myapp.com:8002
>> (it's in testing phase so we don't use any proxying yet).
>
> That's your problem then. demo.myapp.com and demo.myapp.com:8002 are
> considered different domains for the purposes of cookies. You need to
> set up a proxy to get them both on the same port for this to work.

Ah! thanks a lot for clarifying this for me. However, that's really bad news :/

>> So, from the WebSocketHandler, no cookie data can be found.
>>
>>
>>> The most reliable way to see what is being sent to tornado
>>> is to either add logging to tornado's httpserver or use tcpdump or
>>> wireshark.
>>
>> Can you tell me at which point the HTTP headers are sent to tornado?
>
> Tornado reads them from the network when the browser makes a request.
> See HTTPServer._on_headers. tcpdump will let you non-invasively
> eavesdrop on the connection.
>

Thanks, good to know
-Nick