5.1.5 Session

Session

Web developers sometimes opt to store information on the server side rather than the client side. This decision is motivated by a desire to conceal application logic and to minimize the back-and-forth data transmission, a characteristic behavior of cookies. HTTP sessions provide a straightforward mechanism that enables websites to store variables specific to a given visit on the server side. Each user session is uniquely identified by either a session ID or token, assigned by the server.

Session vs Cookies

  • Storage Location:

    • Cookies are stored on the client side.

    • Session variables are stored on the server side.

  • Expiration:

    • Cookies can have a longer lifespan and persist even after the browser is closed.

    • Session variables expire with the session, usually sooner than cookies.

Session Mechanism

  • Session Token (or Session ID):

    • Assigned by the web server to the client.

    • Presented by the client in subsequent requests to be recognized.

    • Acts as a primary key to retrieve client state and associated variables on the server.

Session Cookies

  • Contain a single parameter in a key-value pair format.

  • Examples: SESSION=0wvCbOBWDH8w, PHPSESSID=13An5Z6Uo4pH, JSESSIONID=W7DPUBgw7kTM.

  • Session IDs can be stored in text files, databases, or server memory.

  • Servers can install session cookies after specific client activities, like logging in or opening a page.

  • The browser includes the session cookie in subsequent requests.

  • Session cookies help maintain variables, reducing bandwidth usage.

  • The client uses a login form, and the server responds with a Set-Cookie header containing the session ID.

  • The browser includes the session cookie in subsequent requests.

  • Any subsequent request carries the session cookie, allowing the server to recognize the client.

Alternative:

  • Session IDs can be sent via the GET method appended to the URL.

  • Example: http://example.site/resource.php?sessid=k27qds7h1w.

Last updated