Admin login intermittently failing about channels

[andrewgodwin]

I've just pushed a fix for this to the daphne master branch - the underlying method I was using in Twisted to set headers was overwriting previous ones, so only one cookie came though; now it should work as intended (I've verified I now see both locally).

If one of you could confirm, that would be great.

[AlexejStukov]

I can confirm this. Now the response header looks like this:

Set-Cookie:sessionid=tenxnst7v0w3hi9ex0g97w1paslk1rub; expires=Wed, 30-Mar-2016 13:56:57 GMT; HttpOnly; Max-Age=1209600; Path=/
Set-Cookie:csrftoken=PV9A2vNqierTApgzL3GiyyuUNQjxecf6; expires=Wed, 15-Mar-2017 13:56:57 GMT; Max-Age=31449600; Path=/

Great work and thanks for your fast response.

[orokusaki]

Just to be sure there wasn't something else in my project that was causing the issue (e.g., my custom auth User, other installed apps, etc.), I started a fresh virtualenv, installed only:

django
channels

Then I created a new project via django-admin.py check, added routing.py with just channel_routing = {}, added 'channels' to INSTALLED_APPS, and added the following setting:

CHANNEL_LAYERS = {
    'default': {
        'BACKEND': 'asgiref.inmemory.ChannelLayer',
        'ROUTING': 'check.routing.channel_routing'
    }
}

After a couple tries, I was able to reproduce the issue via manage.py runserver.

Quick note for reproducing this: If it doesn't happen on the first try, log out of the admin, then save your settings file to trigger a restart, then try again. After about the third or so cycle of this, you should be able to reproduce it.

[orokusaki]

Here is some Firebug data to help debug this. During the process of gathering this, I noticed the obvious culprit, which I mention at the bottom.

POST

This is the POST I made to the login form.

Data:

csrfmiddlewaretoken: kz9yRoXhRNQc4pboDnE2jJVVpB3HkGV1
next: /admin/
password: ppppppppp
username: admin

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: csrftoken=kz9yRoXhRNQc4pboDnE2jJVVpB3HkGV1
DNT: 1
Host: localhost:8000
Referer: http://localhost:8000/admin/login/?next=/admin/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0

Response Headers:

Cache-Control: no-cache, max-age=0, must-revalidate, no-store
Content-Type: text/html; charset=utf-8
Expires: Sun, 13 Mar 2016 16:27:29 GMT
Last-Modified: Sun, 13 Mar 2016 16:27:29 GMT
Location: /admin/
Set-Cookie: csrftoken=5jVCmbACV70nfoXLfyUuEoxSTmHmNGZP; expires=Sun, 12-Mar-2017 16:27:29 GMT; Max-Age=31449600; Path=/
Transfer-Encoding: chunked
Vary: Cookie
x-frame-options: SAMEORIGIN

Request Headers From Upload Stream (login form is not multipart, so I'm not sure why this is here):

Content-Length: 103
Content-Type: application/x-www-form-urlencoded

GET

This is the next request (the view redirected to after successful login).

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: csrftoken=5jVCmbACV70nfoXLfyUuEoxSTmHmNGZP
DNT: 1
Host: localhost:8000
Referer: http://localhost:8000/admin/login/?next=/admin/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0

Response Headers:

Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Type: text/html; charset=utf-8
Expires: Sun, 13 Mar 2016 16:27:29 GMT
Last-Modified: Sun, 13 Mar 2016 16:27:29 GMT
Location: /admin/login/?next=/admin/
Transfer-Encoding: chunked
Vary: Cookie
x-frame-options: SAMEORIGIN

Note that there isn't a session ID anywhere. Of course, when things are working normally, the response header from the login POST would include something like this:

Set-Cookie:
  csrftoken=qaF07QheJPARHF8PRjDjKXdboB5RE4pZ; expires=Sun, 12-Mar-2017 16:39:03 GMT; Max-Age=31449600; Path=/
  sessionid=7wogef9pm5wd2p07ss5qof63amdu72dq; expires=Sun, 27-Mar-2016 16:39:03 GMT; HttpOnly; Max-Age=1209600; Path=/

[orokusaki]

The problem is a more fundamental one, but only really noticeable in the case of logging in.

The problem is that, if there are multiple headers with a given name in the list built here, each overrides the previous at some point downstream. I've verified this by testing that the successful login cases correspond to something like this:

# Notice the sessionid is last here
[
    ... other headers ommitted...,
    ('Set-Cookie', b' csrftoken=qhGn3MCtvqgEblCcC72aamY1VcN2lXbF; expires=Sun, 12-Mar-2017 16:53:29 GMT; Max-Age=31449600; Path=/'),
    ('Set-Cookie', b' sessionid=21ma25hibzmhx46aipqvq67r0705pg17; expires=Sun, 27-Mar-2016 16:53:29 GMT; HttpOnly; Max-Age=1209600; Path=/')
]

Whereas, the unsuccessful ones correspond to something like this:

# Notice the csrftoken is last here
[
    ... other headers ommitted...,
    ('Set-Cookie', b' sessionid=21ma25hibzmhx46aipqvq67r0705pg17; expires=Sun, 27-Mar-2016 16:53:29 GMT; HttpOnly; Max-Age=1209600; Path=/'),
    ('Set-Cookie', b' csrftoken=qhGn3MCtvqgEblCcC72aamY1VcN2lXbF; expires=Sun, 12-Mar-2017 16:53:29 GMT; Max-Age=31449600; Path=/')
]

I'm still not sure where they're being handled like this though (rather than being semi-colon delimited), but I'm heading back into the mine now.

[andrewgodwin]

Set-Cookie is actually the only header that can be repeated in the HTTP protocol and has to be kept like that, so there's likely some issues in Daphne's handling of them. Could you update both channels and daphne to master and see if it keeps happening? I've been changing the header spec and handling recently - I'll try to repro here in the meantime.

[orokusaki]

With both Channels and Daphne at master, I'm still seeing the same issue. It's still intermittent. I double checked both libraries in my virtualenv to ensure the code changes from your most recent commits were reflected in each (to ensure it wasn't a pip install from cache).

[AlexejStukov]

It seems I have the same problem, except i get it on my own login-page using the redis-backend and a already fleshed out project. Sometimes it works at the first try, others it doesn't at all, no matter how often i try. Only after restarting the runserver-process I have a chance to log in.
To reproduce the error you also have to restart the process several times (for me it was somewhere near 10 times).

Environment:

autobahn==0.13.0
channels==0.9.5
daphne==0.9.3
Django==1.9.4
Twisted==16.0.0
asgi-redis==0.8.3

Successful attempt:

runserver-log:

[2016/03/16 07:27:42] HTTP POST /accounts/login/ 302 [0.06, 10.116.17.126:49674]
[2016/03/16 07:27:42] HTTP GET / 200 [0.06, 10.116.17.126:49674]
[2016/03/16 07:27:43] WebSocket CONNECT / [10.116.17.126:49675]

Request:

...
Cookie:djdt=hide; sdso=2464ddd841d04413a294e406436d9b59; csrftoken=zwQ6YANuo4sXm4UNRjD9yvP049FdoMX5
...

Response:

...
Set-Cookie:sessionid=nfsb4grbnmb9p2chcqahzyhqu9q06mgw; expires=Wed, 30-Mar-2016 07:27:42 GMT; HttpOnly; Max-Age=1209600; Path=/
...

Unsuccessful attempt:

runserver-log:

[2016/03/16 07:41:50] HTTP POST /accounts/login/ 302 [0.06, 10.116.17.126:49710]
[2016/03/16 07:41:50] HTTP GET / 302 [0.05, 10.116.17.126:49710]
[2016/03/16 07:41:50] HTTP GET /accounts/login/ 200 [0.05, 10.116.17.126:49710]

Request:

...
Cookie:djdt=hide; sdso=2464ddd841d04413a294e406436d9b59; csrftoken=zwQ6YANuo4sXm4UNRjD9yvP049FdoMX5
...

Response:

...
Set-Cookie:csrftoken=uwvw3pKQXTAvinMyhHcnyAxkaHjDdu1r; expires=Wed, 15-Mar-2017 07:41:50 GMT; Max-Age=31449600; Path=/
...

[AlexejStukov]

Also happenig with master-braches of channels and daphne.

[orokusaki]

@andrewgodwin thanks for the quick patch! My apologies for not checking back here in the meantime, so thanks @AlexejStukov for checking.