search

fanout / django-eventstream

Server-Sent Events for Django
MIT License
650 stars 85 forks source link

session cookie missing from reconnect requests #18

Closed AgDude closed 6 years ago

AgDude commented 6 years ago

I am currently evaluating fanout in a development environment using ngrok. I use curl to connect to my django application with a valid session: curl -i https://my-realm.fanoutcdn.com/eventstream/ --cookie "sessionid=my-valid-session-key"

I have a custom manager which assigns channels based on the user. On the first request, this works fine. It seems that there are later requests which lack the session cookie to authenticate the user. If I put a breakpoint in my get_channels_for_request method, I can see that request.COOKIES contains the session id in the first request, and is an empty dictionary in later requests.

From my log files (ngxinx proxy to django runserver):

[11/Aug/2018:14:54:41 +0000] "GET /eventstream/ HTTP/1.1" 200 2077 "-" "curl/7.47.0" 0.322 2827 nate -  
127.0.0.1 - - [11/Aug/2018:14:54:42 +0000] "GET /eventstream/?recover=true&link=next HTTP/1.1" 200 0 "-" "-" 0.025 756 - -
127.0.0.1 - - [11/Aug/2018:14:54:43 +0000] "GET /eventstream/?recover=true&link=next HTTP/1.1" 200 0 "-" "-" 0.024 756 - -
127.0.0.1 - - [11/Aug/2018:14:56:44 +0000] "GET /eventstream/?recover=true&link=next HTTP/1.1" 200 0 "-" "-" 0.032 756 - -
127.0.0.1 - - [11/Aug/2018:14:58:45 +0000] "GET /eventstream/?recover=true&link=next HTTP/1.1" 200 0 "-" "-" 0.031 756 - -

On the first request, the client is getting the correct channels (and if I send an event very quickly I can see it in my terminal). On later requests the user in the ChannleManager is None, so the client is not subscribed to any channels. Note that when I say latter request, I am referring to my nginx logs, as the original curl request has remained open.

This appears to make it impossible to have user-specific channels.

AgDude commented 6 years ago

I should also note that I am not using django-channels. This is django 1.11 and python 2.7

jkarneges commented 6 years ago

Ah yes, this is an open problem when using storage and auth together. We need to figure out a good way to handle it.

The underlying issue is when storage is enabled, django-eventstream instructs the proxy to send recovery requests occasionally (by providing a "next link"), and such recovery requests don't contain the original request headers. The reason the proxy omits the original request headers is because the next link is intended to be potentially sharable by multiple users to enable request collapsing at the proxy. This means the next link ideally contains non-user-specific creds to access the necessary channels.

The quick fix is for your app to just set the cookie value as a request.GET parameter so that it gets applied to the next link. This would be best done in a middleware that runs before user auth. Basically the middleware could do something like this: if sessionid query param present, put it in request.COOKIES, else if sessionid cookie present add it to request.GET. All users will end up with unique next links so they won't be sharable, but that may be just fine and it should get the job done.

If multiple users listen to the same channels, the more optimal solution would be to set shared creds on the next link so that all users have the same next link, and then get_channels_for_request authorizes by user or shared creds depending on what is provided. We might be able to make this less awkward by adding more methods to ChannelManagers, but need to think about it.

AgDude commented 6 years ago

Thanks for the quick response. A session key in a GET param smells bad, but I suppose with https it shouldn't be a vulnerability. I will try that on Monday.

jkarneges commented 6 years ago

A session key in a GET param smells bad

Agreed. I filed an issue on our proxy server project about potentially passing headers in recovery requests. It might be awhile before such a protocol change gets implemented though so hopefully putting auth material in the URL is workable in the meantime.

AgDude commented 6 years ago

Is there a way to completely disable storage? It appears that the GRIP-LINK header is set on the EventResponse regardless of settings. I have been able to make this work by adding middleware which removes that header.

jkarneges commented 6 years ago

It appears that the GRIP-LINK header is set on the EventResponse regardless of settings.

Wow you're right. And actually I believe that's on purpose. Even if storage isn't enabled, Grip-Link is still used for revalidating subscriptions. Hmmmmmmm.

Well, removing the header via middleware will do the trick.

I'll try to come up with a solution very soon, as channel auth via Django user seems to be unusable without hacks.

jkarneges commented 6 years ago

Version 2.2.0 released with a fix. Essentially the library stuffs some state into a query param, signed using settings.SECRET_KEY. This includes the user ID that authenticated the first request, so recovery requests don't need normal Django auth.