librelist archives

« back to archive

html5 and session identification

html5 and session identification

From:
Bruce Adams
Date:
2014-05-19 @ 07:55
Hi,
      I see that flask uses cookies by default for session storage in app.session.
Are there any plans to make it use html5 web storage by default and drop 
back to cookies
only if that is unavailable?


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.

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 

manage the communication with minimal javascript on the clientside.

I know cookies aren't going away anytime soon. This is more a learning 
exercise for doing it right the html5 way.

Regards,

Bruce.

Re: [flask] html5 and session identification

From:
Daniel Neuhäuser
Date:
2014-05-19 @ 08:32
could not decode message

Re: [flask] html5 and session identification

From:
Bruce Adams
Date:
2014-05-20 @ 00:04



>________________________________
> From: Daniel Neuhäuser <ich@danielneuhaeuser.de>
>To: flask@librelist.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' 
policy).
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 
>>
>>manage the communication with minimal javascript on the 
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
>also have no way of pushing Javascript to the clien t from the framework,
so no matter how minimal the javascript
>would be, every user would have to do that by themselves somehow. The 
alternative to users doing that themselves -
>parsing every response and injecting the necessary Javascript - is 
error-prone and simply not acceptable in terms
>of performance.
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 
data  for Javascript
>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
work in javascript. Flask makes a good web-service driven backend but 
there are things that are now easier (okay some already were) to 
manipulate on the client side (I'm particularly thinking of canvas here). 
So given javascript is necessary there may be occasions 
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?
write via javascript, ajax sijax?


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.


Regards,

Bruce