----- Oryginalna wiadomość ----- > Od: "Roberto De Ioris" <[email protected]> > Do: "uWSGI developers and users list" <[email protected]> > Wysłane: czwartek, 14 lipiec 2011 16:29:17 > Temat: Re: [uWSGI] session > > I started working on this ticket (both PSGI and Rack supports a > .session store, so it is a good thing to have it independently of > python), > but have you thought about using flask/werkzeug-style (client-side) > sessions ? > > http://werkzeug.pocoo.org/docs/contrib/securecookie/#module-werkzeug.contrib.securecookie >
For a better understanding: session data - data intended for a specific user. Usually logged on to our application. Nothing to a database session. I have not used werkzeug. But from what I read in the documentation shows that the session data is kept encrypted on the client side we have selected key. This approach has three drawbacks: - If the encryption algorithm is broken, many persons have access to the contents of the session. - If we put too much data for the entire session for every request will be sent in the HTTP headers. - You can send specially crafted data. > expecially for clustered environments they kick asses as you can > avoid session-replication problems between nodes. Here, you're right. Since the session is sent with each request no matter what the node will go. If the node knows the decryption key will read the session data. But this raises some danger. If two requests come from the same client with the same data session. One of those requests will change the contents of the session and sends it as a new cookie. The second request will have no current data. The ideal solution IMHO: - There comes a new POST request with the username and password. - Check if we do not have the currently open session: session_key = uwsgi.session_key_get(my_security_key) - If session_key is None, then - Check to see if username and password is correct, and if so, further - We give the session key: uwsgi.session_key_set(session_key, my_security_key) (session_key, my_security_key - <str> with limited length) At this point is added the Set-Cookie to headers. The solution very similar to werkzeug, but only for sending the key of limited length. It seems: what problem add Set-Cookie header, what mix is uWSGI? Somewhere had to be held global array session keys - those present. uwsgi.session_key_del(session_key, my_security_key) - Also need to exist. If someone produce an HTTP headers are session_key_get() should detect this and return None. An array of session keys must be shared between workers and even between nodes. This solution allows us to safely determine that the request comes from a specific user. Probably it happens so that you'll want to assign to a user's session more data than just the ID / key. Here it seems to me an interesting idea to create a namespace for the Cache. In summary: - It was enough to create something like namespaces for Cache (global, sessionkeys, session1, session2, ...) - Add Cache sharing with other nodes. - It is difficult to predict the size of the session thus the demand for cache size. I'm thinking that first could be solved by prefixes to the Cache keys. It may arises some discussion and there will be new better ideas... -- Łukasz Wróblewski http://www.nri.pl/ - Nowoczesne Rozwiązania Internetowe http://www.hostowisko.pl/ - Profesjonalny i tani hosting http://www.katalog-polskich-firm.pl/ - Najlepszy darmowy katalog firm _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
