Understanding the Cookie Cycle in a Python Test Setting.

Cookies can be quite confusing. Hopefully this will help you understand it.

How do http sessions actually work?  Here is a programmers break down for back-end developers and will give you hopefully a comprehensive understanding:

Consider the following python code block:

import socketserver
from http.server import *
from http import cookies

class Shandler(BaseHTTPRequestHandler):

    def __init__(self, request: bytes, client_address: tuple[str, int], server: socketserver.BaseServer):
        super().__init__(request, client_address, server)
        self.cookie = None

    def do_GET(self):
        self.cookie = self.headers.get("Cookie")
        if self.cookie == None:
            print(f"Setting cookie now")
            self.send_response(200)
            self.send_header("Set-Cookie", "mycookie=213a238d8; Max-Age=50000")
            self.end_headers()

            return("New Connection - setting cookie")
        else:
            print(f"Cookie already set: {self.cookie}")
            return("Cookie already set!")

address = ('', 8001)
handler = Shandler
server = HTTPServer(address, handler)
while True:
    server.serve_forever()

• do_GET is a GENERIC class of BashHTTPRequestHandler when the browser posts a 'GET'
• self.headers.get("Cookie") will fetch the http header cookies from the tuple object inside the current session.  The first time there is no cookie so it is None.
• Think parallel.  This code would exist - and run in parallel as different session users access it.  Thus it would have a completely different set of cookie values if another browser session were to access it.

Setting the cookie on first time:

        if self.cookie == None:
            print(f"Setting cookie now")
            self.send_response(200)
            self.send_header("Set-Cookie", "mycookie=213a238d8; Max-Age=50000")
            self.end_headers()

• 'Set-Cookie' is a standard http transport header accept by industry standard now. Here
• 'Set-Cookie' effectively 'seeds' the browser with the cookie the server requires it to retain for the duration of its session or for Max-Age.  If no duration is specified it is set for 'Session' which means when the user closes the browser the cookie disappears.

The first time this is called we get:

After the browser is seeded with the cookie each time it pulls the same site it will pass this cookie back.

On the second poll of the site we then get the result back to the server which can confirm it is the same user - as in:

This is as simply as it can be explained hopefully and can get the developing programming past the cookie hurdle!

Understand Granularity:

• What many developers would not necessarily note is Browsers work at the IP/Port level.  I was able to intercept another sessions cookies simply because two applications had matching URLs of 127.0.0.1:8000.
• Simplifying this in the above example the browser happened to be holding the cookies from a phpsqladmin session and actually passed them because the browser saw the same IP / port numbers from that session and this code block actually intercepted a different sessions cookies!  Therefore not only must the server look for a cookie - it must look for the 'right' cookie that matches it's logic.
• This presents a MASSIVE security flaw because it would allow anyone with an expired domain to comandeer it - turn on a blank http server then intercept all the cookies quickly if any users were to access it. This has already been done alot