When we log in to a website, with our username and password, we’re not prompted to log in again for each page we visit after, usually until we explicitly log out.
It turns out that there is another web technology called cookies, small pieces of data that a website can ask a browser to store on a user’s computer. Then, when the browser visits that website again, it will automatically send that cookie back, like a virtual handstamp that identifies ourself to the server, without having to enter our login information again. The cookie might store a long random string, to prevent adversaries from easily guessing it, and the server will remember that it corresponds to our account.
When we visit a site like Gmail for the first time, our browser will send HTTP headers like this:
GET / HTTP/1.1
Host: gmail.com
...
Then, Gmail’s server will reply with the login page. After we successfully log in, Gmail’s server will then reply with headers like this:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=value
...
- The
Set-Cookieheader asks our browser to save thesessionandvaluekey-value pair to our computer;valuewill be a long random string or number that identifies us to the server. - If we, as the user, set our browser to not save cookies, we’ll have to log in for every page we visit. But cookies might also identify us to advertisers, who can then track us across different sites we visit, if those sites include embedded images or scripts that are from the same third-party advertising service. So political entities like the EU have passed laws to help ensure companies behind websites are explicit to users about the purpose of cookies they want to store.
When we visit Gmail again later, our browser will send the same value back as part of the Cookie header:
GET / HTTP/1.1
Host: gmail.com
Cookie: session=value
...
- And cookies can be set to expire by the server, which is why after some number of days, we might be asked to log in again.
In today’s source code directory in the CS50 IDE, we’ll first look at the example called store. We’ll cd into the store directory, and call flask run in our terminal to start our IDE’s web server. Then, we can visit the link to see a simple “store”:
- We can change the quantity of each item, and click “Purchase” to see them added to a virtual cart that tell us the count of each item we have.
- We can keep shopping, but even if we close the window and reopen it, we see that our cart still saved the number of each item we added before.
With cookies, we can implement sessions on our server. A session is an abstraction of saved state for each user’s visit to our website; our server might give me a cookie with session=12345 and you a cookie with session=78910, and store some data for each user who visits, based on that session value.
With Flask, we only need a few lines of code to use this abstraction:
...
from flask_session import Session
...
app.config["SESSION_PERMANENT"] = False
app.config["SESSION_TYPE"] = "filesystem"
Session(app)
...
@app.route("/update", methods=["POST"])
def update():
for item in request.form:
session[item] = int(request.form.get(item))
return redirect("/cart")
- We set up our Flask app to use the Session library, and in each of our routes, we’ll have access to a
sessiondictionary, which we can store data in our server’s memory or filesystem for each specific user. - We’ll introduce this library in a bit more detail in this week’s problem set.