{"id":75764,"date":"2020-01-20T12:02:51","date_gmt":"2020-01-20T06:32:51","guid":{"rendered":"https:\/\/www.vskills.in\/certification\/tutorial\/?p=75764"},"modified":"2024-04-12T14:17:16","modified_gmt":"2024-04-12T08:47:16","slug":"cookies","status":"publish","type":"page","link":"https:\/\/www.vskills.in\/certification\/tutorial\/cookies\/","title":{"rendered":"Cookies"},"content":{"rendered":"

Browser developers long ago recognized that HTTP\u2019s statelessness poses a huge problem for Web developers, and thus cookies were born. A cookie is a small piece of information that browsers store on behalf of Web servers. Every time a browser requests a page from a certain server, it gives back the cookie that it initially received. Let\u2019s take a look how this might work. When you open your browser and type in google.com, your browser sends an HTTP request to Google that starts something like this:<\/p>\n

GET \/ HTTP\/1.1
\nHost: google.com
\n…
\nWhen Google replies, the HTTP response looks something like the following:<\/p>\n

HTTP\/1.1 200 OK
\nContent-Type: text\/html
\nSet-Cookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671;
\nexpires=Sun, 17-Jan-2038 19:14:07 GMT;
\npath=\/; domain=.google.com
\nServer: GWS\/2.1
\n…<\/p>\n

Notice the Set-Cookie header. Your browser will store that cookie value (PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671) and serve it back to Google every time you access the site. So the next time you access Google, your browser is going to send a request like this:<\/p>\n

GET \/ HTTP\/1.1
\nHost: google.com
\nCookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671
\n…<\/p>\n

Google then can use that Cookie value to know that you\u2019re the same person who accessed the site earlier. This value might, for example, be a key into a database that stores user information. Google could (and does) use it to display your name on the page.<\/p>\n

Getting and Setting Cookies – When dealing with persistence in Django, most of the time you\u2019ll want to use the higher-level session and\/or user frameworks discussed a little later in this chapter. However, we\u2019ll pause and look at how to read and write cookies at a low level. This should help you understand how the rest of the tools discussed in the chapter actually work, and it will come in handy if you ever need to play with cookies directly. Reading cookies that are already set is incredibly simple. Every request object has a COOKIES object that acts like a dictionary; you can use it to read any cookies that the browser has sent to the view:<\/p>\n

def show_color(request):
\nif “favorite_color” in request.COOKIES:
\nreturn HttpResponse(“Your favorite color is %s” % \\
\nrequest.COOKIES[“favorite_color”])
\nelse:
\nreturn HttpResponse(“You don’t have a favorite color.”)<\/p>\n

Writing cookies is slightly more complicated. You need to use the set_cookie() method on an HttpResponse object. Here\u2019s an example that sets the favorite_color cookie based on a GET parameter:<\/p>\n

def set_color(request):
\nif “favorite_color” in request.GET:
\n# Create an HttpResponse object…
\nresponse = HttpResponse(“Your favorite color is now %s” % \\
\nrequest.GET[“favorite_color”])
\n# … and set a cookie on the response
\nresponse.set_cookie(“favorite_color”,
\nrequest.GET[“favorite_color”])
\nreturn response
\nelse:
\nreturn HttpResponse(“You didn’t give a favorite color.”)<\/p>\n

You can also pass a number of optional arguments to response.set_cookie() that control aspects of the cookie, as shown in Table 12-1.<\/p>\n\n\n\n\n\n\n\n\n\n
Parameter<\/strong><\/td>\nDefault<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n
max_age<\/td>\nNone<\/td>\nAge (in seconds) that the cookie should last. If this parameter is None, the cookie will last only until the browser is closed.<\/td>\n<\/tr>\n
expires<\/td>\nNone<\/td>\nThe actual date\/time when the cookie should expire. It needs to be in the format “Wdy, DD-Mth-YY HH:MM:SS GMT”. If given, this parameter overrides the max_age parameter.<\/td>\n<\/tr>\n
path<\/td>\n“\/”<\/td>\nThe path prefix that this cookie is valid for. Browsers will only pass the cookie back to pages below this path prefix, so you can use this to prevent cookies from being sent to other sections of your site.

<\/p>\n

This is especially useful when you don\u2019t control the top level of your site\u2019s domain.<\/p>\n<\/td>\n<\/tr>\n

domain<\/td>\nNone<\/td>\nThe domain that this cookie is valid for. You can use this parameter to set a cross-domain cookie. For example, domain=”.example.com” will set a cookie that is readable by the domains www.example.com, www2.example.com, and an.other.sub.domain.example.com.

<\/p>\n

If this parameter is set to None, a cookie will only be readable by the domain that set it.<\/p>\n<\/td>\n<\/tr>\n

secure<\/td>\nFalse<\/td>\nIf set to True, this parameter instructs the browser to only return this cookie to pages accessed over HTTPS.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The Mixed Blessing of Cookies<\/strong> – You might notice a number of potential problems with the way cookies work. Let\u2019s look at some of the more important ones:<\/p>\n