Reputation: 8075
Flask.session
for basic session variables (user-id and session-id)Flask.session
and limitations? (Cookies)Cookie based and basically persist only at the client side.
For some session variables that will be regularly read (ie, user permissions, custom application config) it feels awkward to carry all that info around in a cookie, at every single page request and response.
Perhaps that could be a memory-based solution, but I am worried that different Flask app requests could be executed at different threads that would not share the memory-stored session data, or cause conflicts in case of simultaneous reading-writing.
Upvotes: 9
Views: 4605
Reputation: 7672
You are on the right track.
Flask.session
is not for sensitive or long-term data. For those or "if the data is too big" your only option is a database.
But in-between
session cookie and database: for server-side session data you should use:
An extension for Flask that adds support for server-side sessions.
In simple terms if you set up a session, the session
variable is available in all your routes and it behaves like a dictionary. The data stored in this dictionary is individual for each connecting client.
Supports many storage-types like Redis, Memcached, MongoDB, CacheLib, SQLAlchemy and DynamoDB. They must be properly configured (database tc.) before use.
For development or very simple scenarios CacheLib with 'filesystem' is a amazing option.
Doesn't need any additonal package (client-library).
Simple set app.config['SESSION_TYPE'] = 'filesystem'
from flask import Flask, session
from flask_session import Session
app = Flask(__name__)
app.config['SESSION_TYPE'] = 'filesystem'
Session(app)
@app.route('/set/')
def set():
session['key'] = 'value'
return 'ok'
@app.route('/get/')
def get():
return session.get('key', 'not set')
Upvotes: 3
Reputation: 2776
Your instinct is correct, it's probably not the way to do it.
Session data should only be ephemeral information that is not too troublesome to lose and recreate. For example, the user will just have to login again to restore it.
Configuration data or anything else that's necessary on the server and that must survive a logout is not part of the session and should be stored in a DB.
Now, if you really need to easily keep this information client-side and it's not too much of a problem if it's lost, then use a session cookie for logged in/out state and a permanent cookie with a long lifespan for the rest of the configuration information.
If the information is too much size-wise, then the only option I can think of is to store the data, other than the logged in/out state, in a DB.
Upvotes: 2