Re: [flask] html5 and session identification
- Bruce Adams
- 2014-05-20 @ 00:04
> From: Daniel Neuhäuser <email@example.com>
>Sent: Monday, May 19, 2014 9:32 AM
>Subject: Re: [flask] html5 and session identification
>Are there any plans to make it use html5 web storage by default and drop
back to cookies
>>only if that is unavailable?No, I don't think it will ever happen.
>What I'd like to do is provide new sessions with an id and store that on
the client side in sessionStorage,
>>dropping back to a cookie if sessionStorage is unavailable.
>>I would associate the actual session data with the id on the server side.
>What's the point then? You don't use sessionStorage to actually store
session data effectively losing all the benefits
>of the API. Apart from that storing session data on the server while
necessary in some scenarios brings with it
>a huge number of problems that cookies solve very nicely.
>There are security issues with storing certain kinds of data on the
client side. In a practical application the sensitive data often needs to
be stored on the server.
Less sensitive data could be cached in localStorage or sessionStorage.
This is mainly a learning exercise at present. I'm trying out the tools
available rather than building with a specific plan in mind.
I'm also interested in being better able to handle the case where a client
has disabled cookies (often out of a misguided 'all cookies are evil'
Of course, web storage may well be disabled if cookies are.
I believe there is also the option of controlling whether we distinguish
between two tabs in the same browser as one session or as two
which is probably more significant.
I could write a session manager myself but there is no point in
duplicating work if its already been done.
>>Its also a slightly awkward case. I get the impression you would
typically use something like flask-ajax to
clientside.People usually host static files on a subdomain because the
overhead of cookies is considered expensive. This
>approach requires additional HTTP requests and is therefore several
orders of magnitude more expensive still. We
>would be, every user would have to do that by themselves somehow. The
alternative to users doing that themselves -
error-prone and simply not acceptable in terms
I know cookies aren't going away anytime soon. This is more a learning
exercise for doing it right the html5 way.I don't think this is the right
"html5" way at all. sessionStorage provides a useful way to store session
>applications running on the *client* for which no good solution existed
before. It certainly doesn't provide any benefits
>over the current approach for the server side.This is partly the issue
I'm wrestling with. Html5 gives us all these extra goodies for the
presentation layer provided we
there are things that are now easier (okay some already were) to
manipulate on the client side (I'm particularly thinking of canvas here).
when it needs to be templated or generated on the server side and others
where it could perhaps be controlled with
data put into sessionStorage or localStorage or indeed cookies.
You can perhaps see there is an inherant bias on my part towards doing
things on the server side (in a proper programming language).
The real web world of course requires a more pragmatic balance (or I could
use pyjamas or similar instead - but that is a different experiment)
Putting data in cookies is easy. I guess I am curious as to how we put
data in web storage instead.
The should we question is a different matter. I can see that storing a
session id in a cookie makes sense.
(actually I'm trying to keep things mostly stateless and RESTful but it is
not always appropriate)
While I'm here its worth asking two different but vaguely related questions.
1. What is the best way to access e.g. web storage from the server side
(accepting that it is something you should try to avoid in general)
read via DOM?
2. Is there any additional support for session management built in to
flask or available via an add-in?
E.g. generate session id via uuid(), store in the cookie using app.session
but associate it with relevant details such as IP address, browser
etc. and validate those details where appropriate.