|
| 1 | +--- |
| 2 | +title: Server Session |
| 3 | +category: Architectural |
| 4 | +language: en |
| 5 | +--- |
| 6 | + |
| 7 | +## Also known as |
| 8 | + |
| 9 | +Server-side session state pattern |
| 10 | + |
| 11 | +## Intent |
| 12 | + |
| 13 | +Within the context of a client-server relationship, the server is responsible for storing session data in order to maintain state in an otherwise stateless environment. |
| 14 | + |
| 15 | +## Explanation |
| 16 | + |
| 17 | +Real-world example |
| 18 | + |
| 19 | +> Consider a gaming website which stores user profile data such as username, password, highscore, hours played, etc. Since this website is accessed over the internet which uses the HTTP protocol, all requests sent to the server are stateless. In order for the page to display user relevent information without re-authenticating the user on every request a session must be created. Once the session is created the user can access the homescreen, statistics page, setting page, etc. and view profile specific data without needing to login in on every page request. |
| 20 | +
|
| 21 | +In plain words |
| 22 | + |
| 23 | +> Session data is stored on the server, whether in a database, text file or any other form of persistent storage, rather than the client's browser. |
| 24 | +
|
| 25 | +Wikipedia says |
| 26 | + |
| 27 | +> A session token is a unique identifier that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or 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. |
| 28 | +
|
| 29 | +**Programmatic Example** |
| 30 | + |
| 31 | +Consider a website in which a user can log in. Once logged in a session is created to maintain the specific user's data. |
| 32 | + |
| 33 | +First, we have the LoginHandler class, which creates a session identifier and sends it to the client as cookie. |
| 34 | +Notice that not all data is sent to the client, the session creation time and user number are stored on the server side and thus cannot be accessed by the client. |
| 35 | + |
| 36 | +The user logs in by visiting localhost:8080/login |
| 37 | + |
| 38 | +output: |
| 39 | + |
| 40 | +Login successful! |
| 41 | +Session ID: 26434a9c-e734-4a64-97ce-7802b8de46bb |
| 42 | + |
| 43 | +```java |
| 44 | +public class LoginHandler implements HttpHandler { |
| 45 | + |
| 46 | + private Map<String, Integer> sessions; |
| 47 | + private Map<String, Instant> sessionCreationTimes; |
| 48 | + |
| 49 | + public LoginHandler(Map<String, Integer> sessions, Map<String, Instant> sessionCreationTimes) { |
| 50 | + this.sessions = sessions; |
| 51 | + this.sessionCreationTimes = sessionCreationTimes; |
| 52 | + } |
| 53 | + |
| 54 | + @Override |
| 55 | + public void handle(HttpExchange exchange) throws IOException { |
| 56 | + // Generate session ID |
| 57 | + String sessionID = UUID.randomUUID().toString(); |
| 58 | + |
| 59 | + // Store session data (simulated) |
| 60 | + int newUser = sessions.size() + 1; |
| 61 | + sessions.put(sessionID, newUser); |
| 62 | + sessionCreationTimes.put(sessionID, Instant.now()); |
| 63 | + |
| 64 | + // Set session ID as cookie |
| 65 | + exchange.getResponseHeaders().add("Set-Cookie", "sessionID=" + sessionID); |
| 66 | + |
| 67 | + // Send response |
| 68 | + String response = "Login successful!\n" + |
| 69 | + "Session ID: " + sessionID; |
| 70 | + exchange.sendResponseHeaders(200, response.length()); |
| 71 | + OutputStream os = exchange.getResponseBody(); |
| 72 | + os.write(response.getBytes()); |
| 73 | + os.close(); |
| 74 | + } |
| 75 | +} |
| 76 | +``` |
| 77 | + |
| 78 | +When the user logs out the session data is removed from storage using the LogoutHandler class. |
| 79 | + |
| 80 | +The user logs out by visiting localhost:8080/logout |
| 81 | + |
| 82 | +output: |
| 83 | + |
| 84 | +Logout successful! |
| 85 | +Session ID: 26434a9c-e734-4a64-97ce-7802b8de46bb |
| 86 | + |
| 87 | +```java |
| 88 | +public class LogoutHandler implements HttpHandler { |
| 89 | + |
| 90 | + private Map<String, Integer> sessions; |
| 91 | + private Map<String, Instant> sessionCreationTimes; |
| 92 | + |
| 93 | + public LogoutHandler(Map<String, Integer> sessions, Map<String, Instant> sessionCreationTimes) { |
| 94 | + this.sessions = sessions; |
| 95 | + this.sessionCreationTimes = sessionCreationTimes; |
| 96 | + } |
| 97 | + |
| 98 | + @Override |
| 99 | + public void handle(HttpExchange exchange) throws IOException { |
| 100 | + // Get session ID from cookie |
| 101 | + String sessionID = exchange.getRequestHeaders().getFirst("Cookie").replace("sessionID=", ""); |
| 102 | + String currentSessionID = sessions.get(sessionID) == null ? null : sessionID; |
| 103 | + |
| 104 | + // Send response |
| 105 | + |
| 106 | + String response = ""; |
| 107 | + if(currentSessionID == null) { |
| 108 | + response += "Session has already expired!"; |
| 109 | + } else { |
| 110 | + response = "Logout successful!\n" + |
| 111 | + "Session ID: " + currentSessionID; |
| 112 | + } |
| 113 | + |
| 114 | + //Remove session |
| 115 | + sessions.remove(sessionID); |
| 116 | + sessionCreationTimes.remove(sessionID); |
| 117 | + exchange.sendResponseHeaders(200, response.length()); |
| 118 | + OutputStream os = exchange.getResponseBody(); |
| 119 | + os.write(response.getBytes()); |
| 120 | + os.close(); |
| 121 | + } |
| 122 | +} |
| 123 | +``` |
| 124 | + |
| 125 | +Sessions are often given a maximum time in which they will be maintained. The sessionExpirationTask() creates a thread which runs every 1 minute to check for sessions that have exceeded the maximum amount of time, in this case 1 minute and removes the session data from the server's storage. |
| 126 | + |
| 127 | +```java |
| 128 | + private static void startSessionExpirationTask() { |
| 129 | + new Thread(() -> { |
| 130 | + while (true) { |
| 131 | + try { |
| 132 | + System.out.println("Session expiration checker started..."); |
| 133 | + Thread.sleep(SESSION_EXPIRATION_TIME); // Sleep for expiration time |
| 134 | + Instant currentTime = Instant.now(); |
| 135 | + synchronized (sessions) { |
| 136 | + synchronized (sessionCreationTimes) { |
| 137 | + Iterator<Map.Entry<String, Instant>> iterator = sessionCreationTimes.entrySet().iterator(); |
| 138 | + while (iterator.hasNext()) { |
| 139 | + Map.Entry<String, Instant> entry = iterator.next(); |
| 140 | + if (entry.getValue().plusMillis(SESSION_EXPIRATION_TIME).isBefore(currentTime)) { |
| 141 | + sessions.remove(entry.getKey()); |
| 142 | + iterator.remove(); |
| 143 | + } |
| 144 | + } |
| 145 | + } |
| 146 | + } |
| 147 | + System.out.println("Session expiration checker finished!"); |
| 148 | + } catch (InterruptedException e) { |
| 149 | + e.printStackTrace(); |
| 150 | + } |
| 151 | + } |
| 152 | + }).start(); |
| 153 | +} |
| 154 | +``` |
| 155 | + |
| 156 | +## Class diagram |
| 157 | + |
| 158 | + |
| 159 | + |
| 160 | +## Applicability |
| 161 | + |
| 162 | +Use the Adapter pattern when |
| 163 | + |
| 164 | +* When a user logs into a website or web application and you want to keep track of their authentication status. |
| 165 | +* In e-commerce websites when you want to maintain the contents of a user's shopping cart across different pages and visits. |
| 166 | +* When you want to store user preferences and settings, such as language preferences, theme choices, or any other customizable options. |
| 167 | +* When you want to keep track of user activity and behavior on a website for the sake of analytics purposes. |
| 168 | + |
| 169 | +## Tutorials |
| 170 | + |
| 171 | +* [Web Dev Simplified](https://www.youtube.com/watch?v=GihQAC1I39Q&pp=ygUMaHR0cCBzZXNzaW9u) |
| 172 | +* [Hackersploit](https://www.youtube.com/watch?v=zHBpJA5XfDk) |
| 173 | + |
| 174 | +## Consequences |
| 175 | + |
| 176 | +Pros |
| 177 | + |
| 178 | +* HTTP sessions are typically not implemented using one thread per session, but by means of a database with information about the state of each session. The advantage with multiple processes or threads is relaxed complexity of the software, since each thread is an instance with its own history and encapsulated variables. |
| 179 | +* Server-side session management is generally more secure than client-side alternatives like storing session data in cookies. |
| 180 | +* Server-side session management can scale more easily, especially when using distributed caching systems or databases. |
| 181 | + |
| 182 | +Cons |
| 183 | + |
| 184 | +* Large overhead in terms of system resources, and that the session may be interrupted if the system is restarted. |
| 185 | +* 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. |
| 186 | +* If the server hosting the session data goes down or experiences issues, it can disrupt the entire application's functionality, potentially leading to session data loss and user inconvenience. |
| 187 | + |
| 188 | +## Real-world examples |
| 189 | + |
| 190 | +* Express.js Session Middleware |
| 191 | +* Spring Session in Spring Boot |
| 192 | +* Django Session Framework |
| 193 | +* Java Servlet Session Management |
| 194 | + |
| 195 | +## Credits |
| 196 | + |
| 197 | +* [Session(Computer Science)](https://en.wikipedia.org/wiki/Session_(computer_science) |
0 commit comments