[shakna]

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

[ddorian43]

By default flask doesnt have a db. There is flask-sessions extensiom that does this for you.

[shakna]

Or you can just link to a DB directly. A Flask app is just a WSGI app. You can mount and extend it with any kind of Python, no extension necessary.

[ddorian43]

That's what the extension does for you.

[samsonradu]

Can't session data be stored on disk? that's the default PHP behavior.

[ddorian43]

Because you might have multiple webservers.

[samsonradu]

There are solutions for that: Shared NAS, sticky sessions etc.

[ddorian43]

Good luck with maintaining that NAS. Your sticky sessions will logout all users on a server that goes down. It's better to have a db.

Please stop.

[samsonradu]

Of course it's better to have a db doh... I'm replying to your

> By default flask doesnt have a db.

[ddorian43]

The cookie contents can be changed only if you know the secret config.

[shakna]

Or if you can bruteforce the secret, or if there's a vulnerability in the secret, or if... You're relying on the fact that the cryptography will be impregnable, rather than adopting an actual security posture.

Do not trust the data you send to a user, to remain secure.

[ddorian43]

And you're relying on security through obscurity.

[shakna]

No. It's relying on both cryptography, and the inaccessiblity of information. Which is a tried, practiced, and often federally mandated, method of security. Controlling who has access to information is sorta security 101. Don't dump your database to the Internet.

Security through obscurity is allowing REST commands to the /totallysecretaddress/neverleaked/ URI.