7 ms·
Also why would anyone store and read data like { 'groups': [...] } on the client-side? Session cookies are supposed to be identifiers only, with the data store
by samsonradu 2y ago
Also why would anyone store and read data like { 'groups': [...] } on the client-side?
Session cookies are supposed to be identifiers only, with the data stored server-side.
- ddorian43 2y agoBy default sessions in Flask are stored in plaintext: > This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.
- shakna 2y agoThat'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 2y agoBy default flask doesnt have a db. There is flask-sessions extensiom that does this for you.
- shakna 2y agoOr 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 2y agoThat's what the extension does for you.
- samsonradu 2y agoCan't session data be stored on disk? that's the default PHP behavior.
- ddorian43 2y agoBecause you might have multiple webservers.
- samsonradu 2y agoThere are solutions for that: Shared NAS, sticky sessions etc.
- ddorian43 2y agoGood 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 2y agoOf course it's better to have a db doh... I'm replying to your > By default flask doesnt have a db.
- ddorian43 2y agoPeople don't have NAS laying around. And don't use a filesystem as a db, especially a remote filesystem.
- ddorian43 2y agoThe cookie contents can be changed only if you know the secret config.
- shakna 2y agoOr 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 2y agoAnd you're relying on security through obscurity.
- shakna 2y agoNo. 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.
- deleted 2y ago[deleted]