Flask puts the data in the cookie; PHP generates a uniq ID and
saves the to a directory on the server using that ID
(IIRC: /var/lib/php/session/ID), and then puts the ID in
the cookie.
PHP's is more *private* and can be *larger*, but is tied to a single server.
Easier to distribute across multiple servers; less disk or database I/O
"In a big organization, web traffic may be distributed across many servers, in which case the session information needs to be distributed, too. Flask's technique of putting session data in the cookie avoids this problem.But, also isn't it better for things to be in distributed systems though? When the info is distributed it is more fault tolerant with less reliance on one single server, so info can be recovered and retrieved, right? Or in this case we might be very reliant on the cookie itself?
- reading session files from disk: the data comes in with the request, so it's already in memory!
- have session files accumulate on the server
- moving sessions from one server to another (say for load-balancing): the session is in the cookie, so it doesn't matter what server responds to the request.deleting old, abandoned session files from the server"
Yes. I think you are arguing in favor of Flask's approach; aren't you?
But also, yes, we are dependent on the cookie. If it gets lost, the data (say the shopping cart) is gone. So, don't put critical information solely in the session.
For sure! Just remove the authentication info from the session. If the session has {user: ww123}, pop that info out of it.
Great question!
Have I got an exercise for you!