[discussion] consider cookieless sessons about scs HOT 5 CLOSED

In the v2.0.0 release loading and saving of the session data is decoupled from the process of communicating the session token to/from the client, so cookieless sessions are now much easier to implement.

For convenience, I've included a LoadAndSave() middleware in the package which reads/writes the token to a cookie. But you can use this as a template to implement your own middleware which reads/writes the token to an alternative location, like a HTTP header. Here's an example gist: https://gist.github.com/alexedwards/cc6190195acfa466bf27f05aa5023f50

from scs.

This is a good idea.

I've labelled it to include in v2.x because, like you say, it will probably need breaking changes to implement nicely.

There's another open issue for separating the modification and saving of session data (#36) and addressing that first should make implementing this much easier to do.

from scs.

@ChristophPech I'm working on a v2 release at the moment and would like to address this issue if possible. A couple of questions (if you can remember!)...

What was the motivation behind this? Was it because you wanted to communicate the session ID to/from the user in a different HTTP header field? Or were you wanting to use sessions completely outside of the context of a web application and HTTP request-response cycle?

from scs.

I am putting the session cookie into a field in a JSON as well as XML API. Yes, I use mostly HTTP for now but I'd like to stay protocol agnostic as I have different protocol clients for different game engines and different platforms. All data of the protocol is inside the payload so it will be easy to use different transmission channels other than HTTP. For example, a loadbalancing server could collect multiple client requests and send them in bulk to the application server. Additionally messing with cookies on several different client http libraries can be a bit difficult.

The only advantage to use http cookies is that a webbrowser will save, send and expire them automatically. But once the client is not a webbrowser there are only disadvantages left.

from scs.

Awesome. Thanks.

from scs.