librelist archives

« back to archive

Flask sessions

Flask sessions

From:
Live Flex
Date:
2012-07-21 @ 11:24
I'm trying to understand why server-side sessions are an afterthought in
flask? Yes, there are snippets for redis sessions and such, but really for
any decent web app with a modicum of security, the sessions should not be
in a cookie. Not only does Flask use cookies, but they are 'only' signed,
and not encrypted. Sessions should be server side (preferably in a
database) - Rails, Django and just about any PHP framework does it like
this. Is there a reason that Flask does not offer proper server session
functionality, which its such an integral part of most webapps?

Re: [flask] Flask sessions

From:
Anthony Ford
Date:
2012-07-22 @ 03:04
Anthony Ford,
ford.anthonyj@gmail.com,
Research Assistant,
Center for Advanced Radio Astronomy,
University of Texas - Brownsville
On Jul 21, 2012 6:25 AM, "Live Flex" <liveflex8@gmail.com> wrote:

> I'm trying to understand why server-side sessions are an afterthought in
> flask? Yes, there are snippets for redis sessions and such, but really for
> any decent web app with a modicum of security, the sessions should not be
> in a cookie. Not only does Flask use cookies, but they are 'only' signed,
> and not encrypted. Sessions should be server side (preferably in a
> database) - Rails, Django and just about any PHP framework does it like
> this. Is there a reason that Flask does not offer proper server session
> functionality, which its such an integral part of most webapps?
>
>

Re: [flask] Flask sessions

From:
Daniel Neuhäuser
Date:
2012-07-21 @ 13:04
On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
> I'm trying to understand why server-side sessions are an afterthought in
flask? Yes, there are snippets for redis sessions and such[…]
>  
>  

Server-side sessions are not an afterthought, they are just not the 
default. The session mechanism in Flask is designed in such a way that the
actual implementation and thereby the storage of sessions can be easily 
switched.  
  
> […], but really for any decent web app with a modicum of security, the 
sessions should not be in a cookie. Not only does Flask use cookies, but 
they are 'only' signed, and not encrypted.
>  
>  

You throw "security" around like a buzzword with no meaning. If you really
want to bring a convincing argument you have to do more than that: What 
kind of data do you store in sessions that require additional protection? 
Is your case really the general case and if so by what margin?
  
> Sessions should be server side (preferably in a database) - Rails, 
Django and just about any PHP framework does it like this. Is there a 
reason that Flask does not offer proper server session functionality, 
which its such an integral part of most webapps?
>  
>  

  
Rails, Django and apparently "any PHP framework" are full stack frameworks
that provide a mechanism by which web applications using those frameworks 
are able to permanently store data on the server. Flask is a 
"microframework" and does not provide such a mechanism by choice, making 
server-side sessions a huge annoyance. Client-side storage using signed 
cookies is a very well understood and secure alternative that has been 
choosen because it aligns well with Flask's design goals and is a more 
than sufficient solution.

You are not the first to open such an discussion by the way and so far I 
have not seen one or more arguments convincing me that server-side 
sessions are an "integral part of most webapps" and that the current 
design of Flask provides a problem.

What I would be willing to agree to is that the Flask documentation is 
somewhat lacking in regard to this issue. The design defense section 
should probably be amended to include this issue, given how often it comes
up and it might make sense to add a server-side session pattern to the 
Patterns for Flask section.

Re: [flask] Flask sessions

From:
Live Flex
Date:
2012-07-21 @ 13:25
Thanks for the reply. No point in getting into an argument on the security
side; I have no one else to convince but myself. Nevertheless, there are a
number of other arguments for the usefulness of server sessions (larger
data, multiple backends, etc). I understand that flask is a microframework,
but I still think that something like this should be more prominent. Even
if its not enabled by default.

Just to confirm - are flask's cookie signed, and not encrypted? If so, what
are the downsides in encrypting it? Why go for the less secure option by
default?

On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser
<dasdasich@googlemail.com>wrote:

> On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>
> I'm trying to understand why server-side sessions are an afterthought in
> flask? Yes, there are snippets for redis sessions and such[…]
>
> Server-side sessions are not an afterthought, they are just not the
> default. The session mechanism in Flask is designed in such a way that the
> actual implementation and thereby the storage of sessions can be easily
> switched.
>
>
> […], but really for any decent web app with a modicum of security, the
> sessions should not be in a cookie. Not only does Flask use cookies, but
> they are 'only' signed, and not encrypted.
>
> You throw "security" around like a buzzword with no meaning. If you really
> want to bring a convincing argument you have to do more than that: What
> kind of data do you store in sessions that require additional protection?
> Is your case really the general case and if so by what margin?
>
>
> Sessions should be server side (preferably in a database) - Rails, Django
> and just about any PHP framework does it like this. Is there a reason that
> Flask does not offer proper server session functionality, which its such an
> integral part of most webapps?
>
>
> Rails, Django and apparently "any PHP framework" are full stack frameworks
> that provide a mechanism by which web applications using those frameworks
> are able to permanently store data on the server. Flask is a
> "microframework" and does not provide such a mechanism by choice, making
> server-side sessions a huge annoyance. Client-side storage using signed
> cookies is a very well understood and secure alternative that has been
> choosen because it aligns well with Flask's design goals and is a more than
> sufficient solution.
>
> You are not the first to open such an discussion by the way and so far I
> have not seen one or more arguments convincing me that server-side sessions
> are an "integral part of most webapps" and that the current design of Flask
> provides a problem.
>
> What I would be willing to agree to is that the Flask documentation is
> somewhat lacking in regard to this issue. The design defense section should
> probably be amended to include this issue, given how often it comes up and
> it might make sense to add a server-side session pattern to the Patterns
> for Flask section.
>

Re: [flask] Flask sessions

From:
Jay Baker
Date:
2012-07-22 @ 00:09
The way I look at server side session and Flask is that if you want to add
it / use it, go right ahead. You can use the Session interface as pointed
out by chrickso, store session ID in the Flask session and hook it up with
your own server side state in some siple middleware, or integrate with some
other session implementation depending on your needs and environment. This
is one of the beauties of Flask. The simple base and transparency allows
one to truly understand and therefore make the best choice. If a "heavier"
default session implementation was added, then next would be a default ORM
(or something else), and we are down the slippery slope to another Django.

Live Flex, I only have a hunch and can't answer your follow up question
with any authority. But one reason could simply be the CPU cycles.

On Sat, Jul 21, 2012 at 8:25 AM, Live Flex <liveflex8@gmail.com> wrote:

> Thanks for the reply. No point in getting into an argument on the security
> side; I have no one else to convince but myself. Nevertheless, there are a
> number of other arguments for the usefulness of server sessions (larger
> data, multiple backends, etc). I understand that flask is a microframework,
> but I still think that something like this should be more prominent. Even
> if its not enabled by default.
>
> Just to confirm - are flask's cookie signed, and not encrypted? If so,
> what are the downsides in encrypting it? Why go for the less secure option
> by default?
>
>
> On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser <
> dasdasich@googlemail.com> wrote:
>
>> On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>>
>> I'm trying to understand why server-side sessions are an afterthought in
>> flask? Yes, there are snippets for redis sessions and such[…]
>>
>> Server-side sessions are not an afterthought, they are just not the
>> default. The session mechanism in Flask is designed in such a way that the
>> actual implementation and thereby the storage of sessions can be easily
>> switched.
>>
>>
>> […], but really for any decent web app with a modicum of security, the
>> sessions should not be in a cookie. Not only does Flask use cookies, but
>> they are 'only' signed, and not encrypted.
>>
>> You throw "security" around like a buzzword with no meaning. If you
>> really want to bring a convincing argument you have to do more than that:
>> What kind of data do you store in sessions that require additional
>> protection? Is your case really the general case and if so by what margin?
>>
>>
>> Sessions should be server side (preferably in a database) - Rails, Django
>> and just about any PHP framework does it like this. Is there a reason that
>> Flask does not offer proper server session functionality, which its such an
>> integral part of most webapps?
>>
>>
>> Rails, Django and apparently "any PHP framework" are full stack
>> frameworks that provide a mechanism by which web applications using those
>> frameworks are able to permanently store data on the server. Flask is a
>> "microframework" and does not provide such a mechanism by choice, making
>> server-side sessions a huge annoyance. Client-side storage using signed
>> cookies is a very well understood and secure alternative that has been
>> choosen because it aligns well with Flask's design goals and is a more than
>> sufficient solution.
>>
>> You are not the first to open such an discussion by the way and so far I
>> have not seen one or more arguments convincing me that server-side sessions
>> are an "integral part of most webapps" and that the current design of Flask
>> provides a problem.
>>
>> What I would be willing to agree to is that the Flask documentation is
>> somewhat lacking in regard to this issue. The design defense section should
>> probably be amended to include this issue, given how often it comes up and
>> it might make sense to add a server-side session pattern to the Patterns
>> for Flask section.
>>
>
>

Re: [flask] Flask sessions

From:
Kyle Jones
Date:
2012-07-22 @ 04:00
I also cannot answer with much authority, but beyond CPU cycles, I think a
simple answer is this: If you need to store data that the client should not
be able to read on the client itself, you are doing something wrong. You
should be using server-side sessions, in which case encryption doesn't give
you anything extra.

- Kyle

On Sat, Jul 21, 2012 at 5:09 PM, Jay Baker <jbaker.work@gmail.com> wrote:

> The way I look at server side session and Flask is that if you want to add
> it / use it, go right ahead. You can use the Session interface as pointed
> out by chrickso, store session ID in the Flask session and hook it up with
> your own server side state in some siple middleware, or integrate with some
> other session implementation depending on your needs and environment. This
> is one of the beauties of Flask. The simple base and transparency allows
> one to truly understand and therefore make the best choice. If a "heavier"
> default session implementation was added, then next would be a default ORM
> (or something else), and we are down the slippery slope to another Django.
>
> Live Flex, I only have a hunch and can't answer your follow up question
> with any authority. But one reason could simply be the CPU cycles.
>
> On Sat, Jul 21, 2012 at 8:25 AM, Live Flex <liveflex8@gmail.com> wrote:
>
>> Thanks for the reply. No point in getting into an argument on the
>> security side; I have no one else to convince but myself. Nevertheless,
>> there are a number of other arguments for the usefulness of server sessions
>> (larger data, multiple backends, etc). I understand that flask is a
>> microframework, but I still think that something like this should be more
>> prominent. Even if its not enabled by default.
>>
>> Just to confirm - are flask's cookie signed, and not encrypted? If so,
>> what are the downsides in encrypting it? Why go for the less secure option
>> by default?
>>
>>
>> On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser <
>> dasdasich@googlemail.com> wrote:
>>
>>> On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>>>
>>> I'm trying to understand why server-side sessions are an afterthought in
>>> flask? Yes, there are snippets for redis sessions and such[…]
>>>
>>> Server-side sessions are not an afterthought, they are just not the
>>> default. The session mechanism in Flask is designed in such a way that the
>>> actual implementation and thereby the storage of sessions can be easily
>>> switched.
>>>
>>>
>>> […], but really for any decent web app with a modicum of security, the
>>> sessions should not be in a cookie. Not only does Flask use cookies, but
>>> they are 'only' signed, and not encrypted.
>>>
>>> You throw "security" around like a buzzword with no meaning. If you
>>> really want to bring a convincing argument you have to do more than that:
>>> What kind of data do you store in sessions that require additional
>>> protection? Is your case really the general case and if so by what margin?
>>>
>>>
>>> Sessions should be server side (preferably in a database) - Rails,
>>> Django and just about any PHP framework does it like this. Is there a
>>> reason that Flask does not offer proper server session functionality, which
>>> its such an integral part of most webapps?
>>>
>>>
>>> Rails, Django and apparently "any PHP framework" are full stack
>>> frameworks that provide a mechanism by which web applications using those
>>> frameworks are able to permanently store data on the server. Flask is a
>>> "microframework" and does not provide such a mechanism by choice, making
>>> server-side sessions a huge annoyance. Client-side storage using signed
>>> cookies is a very well understood and secure alternative that has been
>>> choosen because it aligns well with Flask's design goals and is a more than
>>> sufficient solution.
>>>
>>> You are not the first to open such an discussion by the way and so far I
>>> have not seen one or more arguments convincing me that server-side sessions
>>> are an "integral part of most webapps" and that the current design of Flask
>>> provides a problem.
>>>
>>> What I would be willing to agree to is that the Flask documentation is
>>> somewhat lacking in regard to this issue. The design defense section should
>>> probably be amended to include this issue, given how often it comes up and
>>> it might make sense to add a server-side session pattern to the Patterns
>>> for Flask section.
>>>
>>
>>
>

Re: [flask] Flask sessions

From:
Craig Younkins
Date:
2012-07-22 @ 19:16
@Kyle: Depends on whether you meant read and modify or just read. For
example, one could set a session flag is_admin where appropriate. This is
still safe with cookie based sessions *if* the cookie is signed or
encrypted, because the client will not be able to modify it and have it
accepted by the server.

Another interesting example: Some magnetic-strip key card access systems
also require a PIN to enter on a keypad where you swipe your card. The idea
here is two-factor security: something you have and something you know. In
cases I've seen, that PIN is actually on the card, which at first glance
defeats the security. But the card data is encrypted, so even if you have
access to a card, you would need to break the encryption before being able
to read the PIN off the card. The data is likely public-key encrypted, and
the card readers have a private key able to read the data.

Craig Younkins


On Sun, Jul 22, 2012 at 12:00 AM, Kyle Jones <kyle@bucebuce.com> wrote:

> I also cannot answer with much authority, but beyond CPU cycles, I think a
> simple answer is this: If you need to store data that the client should not
> be able to read on the client itself, you are doing something wrong. You
> should be using server-side sessions, in which case encryption doesn't give
> you anything extra.
>
> - Kyle
>
>
> On Sat, Jul 21, 2012 at 5:09 PM, Jay Baker <jbaker.work@gmail.com> wrote:
>
>> The way I look at server side session and Flask is that if you want to
>> add it / use it, go right ahead. You can use the Session interface as
>> pointed out by chrickso, store session ID in the Flask session and hook it
>> up with your own server side state in some siple middleware, or integrate
>> with some other session implementation depending on your needs and
>> environment. This is one of the beauties of Flask. The simple base and
>> transparency allows one to truly understand and therefore make the best
>> choice. If a "heavier" default session implementation was added, then next
>> would be a default ORM (or something else), and we are down the slippery
>> slope to another Django.
>>
>> Live Flex, I only have a hunch and can't answer your follow up question
>> with any authority. But one reason could simply be the CPU cycles.
>>
>> On Sat, Jul 21, 2012 at 8:25 AM, Live Flex <liveflex8@gmail.com> wrote:
>>
>>> Thanks for the reply. No point in getting into an argument on the
>>> security side; I have no one else to convince but myself. Nevertheless,
>>> there are a number of other arguments for the usefulness of server sessions
>>> (larger data, multiple backends, etc). I understand that flask is a
>>> microframework, but I still think that something like this should be more
>>> prominent. Even if its not enabled by default.
>>>
>>> Just to confirm - are flask's cookie signed, and not encrypted? If so,
>>> what are the downsides in encrypting it? Why go for the less secure option
>>> by default?
>>>
>>>
>>> On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser <
>>> dasdasich@googlemail.com> wrote:
>>>
>>>> On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>>>>
>>>> I'm trying to understand why server-side sessions are an afterthought
>>>> in flask? Yes, there are snippets for redis sessions and such[…]
>>>>
>>>> Server-side sessions are not an afterthought, they are just not the
>>>> default. The session mechanism in Flask is designed in such a way that the
>>>> actual implementation and thereby the storage of sessions can be easily
>>>> switched.
>>>>
>>>>
>>>> […], but really for any decent web app with a modicum of security, the
>>>> sessions should not be in a cookie. Not only does Flask use cookies, but
>>>> they are 'only' signed, and not encrypted.
>>>>
>>>> You throw "security" around like a buzzword with no meaning. If you
>>>> really want to bring a convincing argument you have to do more than that:
>>>> What kind of data do you store in sessions that require additional
>>>> protection? Is your case really the general case and if so by what margin?
>>>>
>>>>
>>>> Sessions should be server side (preferably in a database) - Rails,
>>>> Django and just about any PHP framework does it like this. Is there a
>>>> reason that Flask does not offer proper server session functionality, which
>>>> its such an integral part of most webapps?
>>>>
>>>>
>>>> Rails, Django and apparently "any PHP framework" are full stack
>>>> frameworks that provide a mechanism by which web applications using those
>>>> frameworks are able to permanently store data on the server. Flask is a
>>>> "microframework" and does not provide such a mechanism by choice, making
>>>> server-side sessions a huge annoyance. Client-side storage using signed
>>>> cookies is a very well understood and secure alternative that has been
>>>> choosen because it aligns well with Flask's design goals and is a more than
>>>> sufficient solution.
>>>>
>>>> You are not the first to open such an discussion by the way and so far
>>>> I have not seen one or more arguments convincing me that server-side
>>>> sessions are an "integral part of most webapps" and that the current design
>>>> of Flask provides a problem.
>>>>
>>>> What I would be willing to agree to is that the Flask documentation is
>>>> somewhat lacking in regard to this issue. The design defense section should
>>>> probably be amended to include this issue, given how often it comes up and
>>>> it might make sense to add a server-side session pattern to the Patterns
>>>> for Flask section.
>>>>
>>>
>>>
>>
>

Re: [flask] Flask sessions

From:
Frank Murphy
Date:
2012-07-23 @ 14:30
Flask can also very easily integrate with session middleware: see 
http://flask.pocoo.org/snippets/61/. This example uses beaker, which has 
easily swappable backends.

On 07/22/2012 03:16 PM, Craig Younkins wrote:
> @Kyle: Depends on whether you meant read and modify or just read. For 
> example, one could set a session flag is_admin where appropriate. This 
> is still safe with cookie based sessions /if/ the cookie is signed or 
> encrypted, because the client will not be able to modify it and have 
> it accepted by the server.
>
> Another interesting example: Some magnetic-strip key card access 
> systems also require a PIN to enter on a keypad where you swipe your 
> card. The idea here is two-factor security: something you have and 
> something you know. In cases I've seen, that PIN is actually on the 
> card, which at first glance defeats the security. But the card data is 
> encrypted, so even if you have access to a card, you would need to 
> break the encryption before being able to read the PIN off the card. 
> The data is likely public-key encrypted, and the card readers have a 
> private key able to read the data.
>
> Craig Younkins
>
>
> On Sun, Jul 22, 2012 at 12:00 AM, Kyle Jones <kyle@bucebuce.com 
> <mailto:kyle@bucebuce.com>> wrote:
>
>     I also cannot answer with much authority, but beyond CPU cycles, I
>     think a simple answer is this: If you need to store data that the
>     client should not be able to read on the client itself, you are
>     doing something wrong. You should be using server-side sessions,
>     in which case encryption doesn't give you anything extra.
>
>     - Kyle
>
>
>     On Sat, Jul 21, 2012 at 5:09 PM, Jay Baker <jbaker.work@gmail.com
>     <mailto:jbaker.work@gmail.com>> wrote:
>
>         The way I look at server side session and Flask is that if you
>         want to add it / use it, go right ahead. You can use the
>         Session interface as pointed out by chrickso, store session ID
>         in the Flask session and hook it up with your own server side
>         state in some siple middleware, or integrate with some other
>         session implementation depending on your needs and
>         environment. This is one of the beauties of Flask. The simple
>         base and transparency allows one to truly understand and
>         therefore make the best choice. If a "heavier" default session
>         implementation was added, then next would be a default ORM (or
>         something else), and we are down the slippery slope to another
>         Django.
>
>         Live Flex, I only have a hunch and can't answer your follow up
>         question with any authority. But one reason could simply be
>         the CPU cycles.
>
>         On Sat, Jul 21, 2012 at 8:25 AM, Live Flex
>         <liveflex8@gmail.com <mailto:liveflex8@gmail.com>> wrote:
>
>             Thanks for the reply. No point in getting into an argument
>             on the security side; I have no one else to convince but
>             myself. Nevertheless, there are a number of other
>             arguments for the usefulness of server sessions (larger
>             data, multiple backends, etc). I understand that flask is
>             a microframework, but I still think that something like
>             this should be more prominent. Even if its not enabled by
>             default.
>
>             Just to confirm - are flask's cookie signed, and not
>             encrypted? If so, what are the downsides in encrypting it?
>             Why go for the less secure option by default?
>
>
>             On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser
>             <dasdasich@googlemail.com
>             <mailto:dasdasich@googlemail.com>> wrote:
>
>                 On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>>                 I'm trying to understand why server-side sessions are
>>                 an afterthought in flask? Yes, there are snippets for
>>                 redis sessions and such[…]
>                 Server-side sessions are not an afterthought, they are
>                 just not the default. The session mechanism in Flask
>                 is designed in such a way that the actual
>                 implementation and thereby the storage of sessions can
>                 be easily switched.
>>                 […], but really for any decent web app with a modicum
>>                 of security, the sessions should not be in a cookie.
>>                 Not only does Flask use cookies, but they are 'only'
>>                 signed, and not encrypted.
>                 You throw "security" around like a buzzword with no
>                 meaning. If you really want to bring a convincing
>                 argument you have to do more than that: What kind of
>                 data do you store in sessions that require additional
>                 protection? Is your case really the general case and
>                 if so by what margin?
>>                 Sessions should be server side (preferably in a
>>                 database) - Rails, Django and just about any PHP
>>                 framework does it like this. Is there a reason that
>>                 Flask does not offer proper server session
>>                 functionality, which its such an integral part of
>>                 most webapps?
>                 Rails, Django and apparently "any PHP framework" are
>                 full stack frameworks that provide a mechanism by
>                 which web applications using those frameworks are able
>                 to permanently store data on the server. Flask is a
>                 "microframework" and does not provide such a mechanism
>                 by choice, making server-side sessions a huge
>                 annoyance. Client-side storage using signed cookies is
>                 a very well understood and secure alternative that has
>                 been choosen because it aligns well with Flask's
>                 design goals and is a more than sufficient solution.
>
>                 You are not the first to open such an discussion by
>                 the way and so far I have not seen one or more
>                 arguments convincing me that server-side sessions are
>                 an "integral part of most webapps" and that the
>                 current design of Flask provides a problem.
>
>                 What I would be willing to agree to is that the Flask
>                 documentation is somewhat lacking in regard to this
>                 issue. The design defense section should probably be
>                 amended to include this issue, given how often it
>                 comes up and it might make sense to add a server-side
>                 session pattern to the Patterns for Flask section.
>
>
>
>
>

Re: [flask] Flask sessions

From:
Live Flex
Date:
2012-07-23 @ 15:27
Thanks for the reply Frank. I am aware of Beaker, but even the author
doesn't really have much faith in it:

"Beaker itself has just been a problem that's too boring for anyone to
bother replacing, but it does have a lot of bugs particularly in the
session handling"

Still looking for a really definitive and conclusive way to handle db
sessions...

On Mon, Jul 23, 2012 at 3:30 PM, Frank Murphy <fmurphy@arbor.net> wrote:

>  Flask can also very easily integrate with session middleware: see
> http://flask.pocoo.org/snippets/61/. This example uses beaker, which has
> easily swappable backends.
>
>
> On 07/22/2012 03:16 PM, Craig Younkins wrote:
>
> @Kyle: Depends on whether you meant read and modify or just read. For
> example, one could set a session flag is_admin where appropriate. This is
> still safe with cookie based sessions *if* the cookie is signed or
> encrypted, because the client will not be able to modify it and have it
> accepted by the server.
>
>  Another interesting example: Some magnetic-strip key card access systems
> also require a PIN to enter on a keypad where you swipe your card. The idea
> here is two-factor security: something you have and something you know. In
> cases I've seen, that PIN is actually on the card, which at first glance
> defeats the security. But the card data is encrypted, so even if you have
> access to a card, you would need to break the encryption before being able
> to read the PIN off the card. The data is likely public-key encrypted, and
> the card readers have a private key able to read the data.
>
>  Craig Younkins
>
>
> On Sun, Jul 22, 2012 at 12:00 AM, Kyle Jones <kyle@bucebuce.com> wrote:
>
>> I also cannot answer with much authority, but beyond CPU cycles, I think
>> a simple answer is this: If you need to store data that the client should
>> not be able to read on the client itself, you are doing something wrong.
>> You should be using server-side sessions, in which case encryption doesn't
>> give you anything extra.
>>
>>  - Kyle
>>
>>
>> On Sat, Jul 21, 2012 at 5:09 PM, Jay Baker <jbaker.work@gmail.com> wrote:
>>
>>> The way I look at server side session and Flask is that if you want to
>>> add it / use it, go right ahead. You can use the Session interface as
>>> pointed out by chrickso, store session ID in the Flask session and hook it
>>> up with your own server side state in some siple middleware, or integrate
>>> with some other session implementation depending on your needs and
>>> environment. This is one of the beauties of Flask. The simple base and
>>> transparency allows one to truly understand and therefore make the best
>>> choice. If a "heavier" default session implementation was added, then next
>>> would be a default ORM (or something else), and we are down the slippery
>>> slope to another Django.
>>>
>>> Live Flex, I only have a hunch and can't answer your follow up question
>>> with any authority. But one reason could simply be the CPU cycles.
>>>
>>> On Sat, Jul 21, 2012 at 8:25 AM, Live Flex <liveflex8@gmail.com> wrote:
>>>
>>>> Thanks for the reply. No point in getting into an argument on the
>>>> security side; I have no one else to convince but myself. Nevertheless,
>>>> there are a number of other arguments for the usefulness of server sessions
>>>> (larger data, multiple backends, etc). I understand that flask is a
>>>> microframework, but I still think that something like this should be more
>>>> prominent. Even if its not enabled by default.
>>>>
>>>>  Just to confirm - are flask's cookie signed, and not encrypted? If
>>>> so, what are the downsides in encrypting it? Why go for the less secure
>>>> option by default?
>>>>
>>>>
>>>>  On Sat, Jul 21, 2012 at 2:04 PM, Daniel Neuhäuser <
>>>> dasdasich@googlemail.com> wrote:
>>>>
>>>>> On Saturday, July 21, 2012 at 1:24 PM, Live Flex wrote:
>>>>>
>>>>>   I'm trying to understand why server-side sessions are an
>>>>> afterthought in flask? Yes, there are snippets for redis sessions and
>>>>> such[…]
>>>>>
>>>>>  Server-side sessions are not an afterthought, they are just not the
>>>>> default. The session mechanism in Flask is designed in such a way that the
>>>>> actual implementation and thereby the storage of sessions can be easily
>>>>> switched.
>>>>>
>>>>>
>>>>>  […], but really for any decent web app with a modicum of security,
>>>>> the sessions should not be in a cookie. Not only does Flask use cookies,
>>>>> but they are 'only' signed, and not encrypted.
>>>>>
>>>>> You throw "security" around like a buzzword with no meaning. If you
>>>>> really want to bring a convincing argument you have to do more than that:
>>>>> What kind of data do you store in sessions that require additional
>>>>> protection? Is your case really the general case and if so by what margin?
>>>>>
>>>>>
>>>>>   Sessions should be server side (preferably in a database) - Rails,
>>>>> Django and just about any PHP framework does it like this. Is there a
>>>>> reason that Flask does not offer proper server session functionality, which
>>>>> its such an integral part of most webapps?
>>>>>
>>>>>
>>>>>  Rails, Django and apparently "any PHP framework" are full stack
>>>>> frameworks that provide a mechanism by which web applications using those
>>>>> frameworks are able to permanently store data on the server. Flask is a
>>>>> "microframework" and does not provide such a mechanism by choice, making
>>>>> server-side sessions a huge annoyance. Client-side storage using signed
>>>>> cookies is a very well understood and secure alternative that has been
>>>>> choosen because it aligns well with Flask's design goals and is a more than
>>>>> sufficient solution.
>>>>>
>>>>>  You are not the first to open such an discussion by the way and so
>>>>> far I have not seen one or more arguments convincing me that server-side
>>>>> sessions are an "integral part of most webapps" and that the current design
>>>>> of Flask provides a problem.
>>>>>
>>>>>  What I would be willing to agree to is that the Flask documentation
>>>>> is somewhat lacking in regard to this issue. The design defense section
>>>>> should probably be amended to include this issue, given how often it comes
>>>>> up and it might make sense to add a server-side session pattern to the
>>>>> Patterns for Flask section.
>>>>>
>>>>
>>>>
>>>
>>
>
>

Re: [flask] Flask sessions

From:
chrickso
Date:
2012-07-21 @ 13:14
Check this out: http://flask.pocoo.org/snippets/51/

I don't understand how client side cookies that cannot be read or altered
do not provide at least a modicum of security...

- chrickso
On Jul 21, 2012 6:28 AM, "Live Flex" <liveflex8@gmail.com> wrote:

> I'm trying to understand why server-side sessions are an afterthought in
> flask? Yes, there are snippets for redis sessions and such, but really for
> any decent web app with a modicum of security, the sessions should not be
> in a cookie. Not only does Flask use cookies, but they are 'only' signed,
> and not encrypted. Sessions should be server side (preferably in a
> database) - Rails, Django and just about any PHP framework does it like
> this. Is there a reason that Flask does not offer proper server session
> functionality, which its such an integral part of most webapps?
>
>