[MUSIC] When you have multiple mobile clients talking to a web application, which we'll say down here, in a servlet within that web application. One of the things you have to think about is, how does this server remember all of the information in the state related to the particular client that's talking to it? So for example, let's say this is our mobile device, and we're writing a banking application. And every time the user goes and checks their account balance, one of the things we want to make sure of, is that, that mobile device has logged in or established its identity with this servlet. Now, the way that we do this in HTTP is by establishing what's called a session. And basically, this is an ongoing communication or dialog between the mobile device and the servlet. So, the session is the dialog, or the conversation, between the mobile device and the servlet. And a session is where the servlet, or the server, keeps track of the state of the conversation, what's been said so far? What do I know about this client? What do I want to remember the next time that they send me a request? So, what is a session and why is it important in terms of talking over HTTP? Well, if you think about the way that this mobile device is going to begin talking to the server, is it's going to send a request and it’s going to receive some data or some type of response, that’s going to be sent back by the server. So, that data will come back. And then later, on it may go on and send another request, and get some more data back. And so there’s a connection that gets established, some data that gets sent, sent back, and then that mobile device may disconnect for some period of time. So for example, you may go into your banking application. You may log into your banking application. Now, then your phone is with you, you're on a train, or on public transit. You know, we wouldn't want to be texting while we're driving, or checking our bank account's while we're driving. But maybe, we're on the bus. And suddenly as we're driving along, we lose our signal and our connection. And so, the next request that we send in order to check our account balance, it doesn't have the same connection. It is a completely new HTTP request that's being sent to the server and a completely new response that we're expecting. So, one of the things that the server has to do, is maintain that conversation, even though that mobile device was out of contact for some period of time, and there was no direct underlying network connection to the device. We still want the server to remember that, that conversation, that dialogue with the device, was ongoing. And that maybe, that first request was a login and the second request is going to be, you know, view the account balance. And we still want that person to be able to view their account balance. We still that, want that device to be able to access that information, because we still trust that session or that communication, that dialogue that was ongoing between the device and the server. So, sessions are this whole process of maintaining a dialogue with a device and maintaining information about that device, in a state of the conversation, across multiple HTTP requests. So that, if you use one HTTP request to log in, and then ten minutes from now you use another request to access the account balance, the session and the way that you track sessions determines if you'll allow that to go through and you'll remember who that mobile client is. Or, if they don't have a session, then you'll force them to log in again. But sessions are the way that we maintain and remember those conversations with the mobile clients. Now, an important consideration on the servlet is, and on the server side are things like, how long do we maintain a session? [BLANK_AUDIO] Because, if we maintain a session too long, maybe we're wasting resources on the serve. So, every time we begin a conversation, we start a new session, well, that session's going to allocate memory on the server, that's going to take up resources that aren't available to other clients. So, how long we maintain sessions will affect the resources that we have to keep on the server. It also may have security implications. Maybe we want to force the person to log out and log back in every so often, to ensure that, that device hasn't been taken or stolen, or something else. So, we have to maintain a bunch of information. What information should we maintain? [BLANK_AUDIO] Is in the session? So, what information is in the session? So, what do we care about in this communication dialogue between the server and the device? These are all important questions about sessions, when we're designing and building a cloud-based service to support mobile devices. And then, we typically want to use some type of authentication framework, so that we can strongly authenticate and trust mobile clients, and associate data with them and ensure that if they begin a session, that somebody doesn't come along from outside and steal a session. So, we have to worry about and insure that once we begin tracking a session, that there's no way that somebody can intercept that session data and use it to exploit the server in some way, or exploit the client's data in some way. So, these are all important considerations. So, how do we normally track sessions? Well, the first thing that I, I want to emphasize is that you should very rarely reinvent the establishment of session and the tracking of sessions in those mechanisms. There are many libraries and frameworks that are out there that have been battle-hardened, very carefully audited for security purposes, and your first thing that you should do is go and look for one of those libraries. You do not want to reinvent your own authentication mechanisms or session mechanisms, wherever possible. Instead, you want to use something that's well understood, well tested, and has known security properties and is continually being analyzed for security quality. So, go and find a session library first. But just to give you a, a rough idea of how they understand work, there's a couple different ways. One is, session libraries normally take advantage of sending back to the mobile device, some form of cookie that is used to help remember the session for the server. So, when the mobile device is going to send a request, it will normally send a cookie, with session info. And what session information you send will depend upon how sensitive the session is, and how paranoid you are. So, the, the very simplest thing is you don't want to send anything to the client, other than an identifier. So, you store all of the really juicy details about the session on the server, so you can have purely server-side sessions. And you have no data on the client. So, that's one extreme. At the other extreme, you could have a lot of data on the client, and only just store sensitive things on the server side. So, you can also have you know, partial data on the server. [BLANK_AUDIO] And partial data on the mobile device. [BLANK_AUDIO] So, there's a variety of different setups. The cookie is typically what's used if you're going to store some data on the mobile device, typically that will be communicated back to the device through a cookie. Now, if you're using a mobile client, you can do more than that. You could send back data and have your own protocol built off of HTTP, where you send other things back and you just expect the device to know how to handle those things and store them. Maybe you encode information in the headers that are sent in the request. But there's mult, multiple ways that the device can store data, or cookies, or other bits of information that it then sends to the server. And then whenever the server sees that bit of data, it can use it to establish the identity of the device. And remember, this is the same device that sent the log in request five minutes ago, that's now accessing the account data. So, what that bit of data is that the mobile device stores, is a little cookie, a little, a little bit of information that helps the server figure out the identity of that device when it reestablishes communication with the server in a later request. So, sessions are the maintenance of the conversation, and the state of a conversation, across multiple HTTP requests. Cookies are a common way that we store information on the mobile device to help the server figure out that this is the same person sending multiple requests. Or, the same device sending multiple requests, and therefore, it should associate them with the same state. But, we can have any type of information sent back to the mobile client, in order to help the server establish that identity. The most common types of things that get sent back to the mobile device are cryptographic tokens, a session ID, some form of information that would be very hard for the mobile device, or some other client, to guess on its own, and send to the server in order to establish a session that maybe wasn't his, its own. Or, to confuse the server, and something that will be unique across all of the different clients. So, we want to create sessions that are unique, typically, across each individual client so we can associate state information with each individual client. So, this is the concept of a session, and the basic idea is, how do we track state when we're going to have multiple individual conversations or HTTP requests that are going to be sent between the device and the server? And we want all of those different requests, conversations, to be considered one conversation, one solid session, between the mobile device and the server and it's communication
