cookie-related processing in Python's Django framework
The developer of the browser realized early on that HTTP's stateless behavior posed a big problem for Web developers, and (cookies) came into being. Cookies are a small piece of information that a browser stores for a WEB server. Each time the browser requests a page from a server, it sends back to the server the cookies it received
Let's see how it works. When you open your browser and access google.com, your browser will send an HTTP request to Google, as in the starting section:
Get/http/1.1host:google.com ...
When Google responds, the HTTP response is this:
http/1.1 okcontent-type:text/htmlset-cookie:pref=id=5b14f22bdaf1e81c:tm=1167000671:lm=1167000671; Expires=sun, 17-jan-2038 19:14:07 GMT; path=/; domain=.google.comserver:gws/2.1 ...
Pay attention to Set-cookie's head. Your browser will store the cookie value (pref=id=5b14f22bdaf1e81c:tm=1167000671:lm=1167000671), and this cookie value will be echoed every time you visit a Google site. So the next time you visit Google, your browser will send a request like this:
get/http/1.1host:google.comcookie:pref=id=5b14f22bdaf1e81c:tm=1167000671:lm=1167000671 ...
So the value of the cookie tells Google that you are the person who visited the Google site earlier. This value may be the key for storing user information in the database, which can be used to display your user name on the page. Google will (and currently) use it to display the username of your account on the page.
Access to Cookies
Working with persistence in Django, most of the time you will prefer to use the high-level session and/or the user framework that is discussed later. But before we do, we need to stop at the bottom to see how to read and write cookies. This will help you understand how the tools that are discussed later in this section work, and if you need to manipulate cookies yourself, this will also help.
It is extremely easy to read cookies that have been set up. Every ' HttpRequest ' object has a ' cookie ' object that behaves like a dictionary, and you can use it to read any COOKIES sent to the view by any browser.
def show_color (Request): if "Favorite_Color" in Request. COOKIES: return HttpResponse ("Your Favorite color is%s"% request.) cookies["Favorite_Color"]) else: return HttpResponse ("You don't have a favorite color.")
Writing cookies is a bit more complicated. You need to use the Set_cookie () method of the HttpResponse object. Here's a set of Favorite_Color based on the GET parameter.
Examples of cookies:
--edit http://www.aichengxu.com/view/61768--def Set_color (Request): if "Favorite_Color" in Request. GET: # Create an HttpResponse object ... Response = HttpResponse ("Your favorite color is now%s"% request. get["Favorite_Color"]) # ... and set a cookie on the response Response.set_cookie ("Favorite_Color", Request. get["Favorite_Color"]) return response else: return HttpResponse ("You didn ' t give a favorite color.")
You can pass some optional parameters to Response.set_cookie () to control the behavior of cookies, refer to: http://www.aichengxu.com/view/61768
A mixed cookie
Perhaps you have noticed that the way cookies work can cause problems. Let's take a look at some of the more important questions:
The storage of cookies is voluntary, and a client does not necessarily accept or store cookies. In fact, all browsers allow the user to control whether or not to accept cookies. If you want to know how important cookies are to web apps, you can try opening the browser's options:
Although cookies are widely used, they are still considered unreliable. This means that developers must check if they can receive cookies before using cookies.
Cookies (especially those that are not transmitted over HTTPS) are very insecure. Because HTTP data is sent in plaintext, it is particularly susceptible to sniffing attacks. In other words, sniffer attackers can intercept and read cookies on the network, so you should absolutely avoid storing sensitive information in cookies. This means that you should not use cookies to store any sensitive information.
There is also a more insidious attack called a "middleman" in which an attacker intercepts a cookie and uses it for another user. The 19th chapter will discuss in depth the nature of this attack and how to avoid it.
Even the cookie returned from the intended recipient is unsafe. In most browsers, you can easily modify the information in cookies. Experienced users can even construct an HTTP request manually with a tool such as mechanize (http://wwwsearch.sourceforge.net/mechanize/).
Therefore, it is not possible to store sensitive data that may be tampered with in cookies. Store isloggedin=1 in cookies to identify that the user is already logged in. The number of sites that make such mistakes is unbelievable, and the security system that bypasses them is a breeze.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
cookie-related processing in Python's Django framework
