Overview#Session is a semi-permanent interactive information interchange, also known as a dialogue, a protocol conversation or a meeting, or Communication between two or more communicating Entities.
- HTTP Session, which allow associating information with individual visitors
- A telnet remote login session
Session Layer example:
Transport Layer example:
- A TCP Session, which is synonymous to a TCP virtual circuit, a TCP connection, or an established TCP socket.
HTTP/1.0 was thought to only allow a single Request-Response during one Web/HTTP Session. Protocol version HTTP/1.1 improved this by completing the Common Gateway Interface (CGI), making it easier to maintain the Web Session and supporting HTTP Cookies and file uploads.
Most Client-Server Exchange sessions are maintained by the Transport Layer - a single connection for a single session. However each transaction phase of a Web/HTTP session creates a separate connection. Maintaining session continuity between phases requires a Session ID. The Session ID is embedded within the <A HREF> or <FORM> links of dynamic web pages so that it is passed back to the CGI. CGI then uses the Session ID to ensure session continuity between transaction phases. One advantage of one connection-per-phase is that it works well over low bandwidth (modem) connections.
Server-side web Session#Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in some embedded systems with no storage. The load-balancing problem can be solved by using shared storage or by applying forced peering between each client and a single server in the cluster, although this can compromise system efficiency and load distribution.
A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM for storage of session data. This method is applicable for servers with a limited number of clients (e.g. router or access point with infrequent or disallowed access to more than one client at a time).
This mechanism may work well in some contexts; however, data stored on the client is vulnerable to tampering by the user or by software that has access to the client computer. To use client-side sessions where confidentiality and integrity are required, the following must be guaranteed:
- Confidentiality: Nothing apart from the server should be able to interpret session data.
- Data integrity: Nothing apart from the server should manipulate session data (accidentally or maliciously).
- Authenticity: Nothing apart from the server should be able to initiate valid sessions.
Transmitting state back and forth with every request is only practical when the size of the cookie is small. In essence, client-side sessions trade server disk space for the extra bandwidth that each web request will require. Moreover, web browsers limit the number and size of cookies that may be stored by a web site. To improve efficiency and allow for more session data, the server may compress the data before creating the cookie, decompressing it later when the cookie is returned by the client.token as an HTTP cookie and/or sends it as a parameter in HTTP GET or HTTP POST queries. The reason to use session tokens is that the client only has to handle the identifier—all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier.
Examples of the names that some programming languages use when naming their HTTP cookie include:
More Information#There might be more information for this subject on one of the following:
- AS Exchange
- Channel Binding
- Cipher Suite
- Circuit switching
- Client-Server Exchange
- Credential Management API
- Cross-site request forgery
- DNC Decryption Flow
- Elevated Token
- Identity Broker
- Identity Correlation
- Internet Key Exchange
- JSON Web Token Claims
- Key Distribution Center
- Key Generation
- Load Balancing
- Local Security Authority
- Local Security Authority Subsystem Service
- Logging Out
- MSFT Access Token
- OpenID Connect Back-Channel Logout
- OpenID Connect Front-Channel Logout
- Policy Based Management System
- SAML V2.0
- Session Affinity
- Session ID
- Session Key
- Session Layer
- Session Management
- Shared Secret
- Single Logout
- Single Logout Profile
- Standards Based SSO
- Ticket Granting Ticket
- Token Storage
- Unbind Request
- Web Blog_blogentry_230717_1
- Why Use Tokens
- Windows Logon