No session data is stored server side, the cookie contains a token that authenticates user.
Take the 2-minute tour
×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
closed as unclear what you're asking by MainMa, gnat, GlenH7, Martijn Pieters, MichaelT May 14 at 23:00Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question. |
|||||||||
|
|||||||||
|
Yes, an authentication cookie is still state. It is state that is being transferred between the browser and server on every call - if deleted, the server doesn't know about the caller. The state is the authentication token. It might be small, but it is still state. |
|||||||||||||||||||||
|
|
When considering statelessness of a web service, the key question is: is a particular server tied to a particular client? HTTP is a stateless protocol. That means that I can make an HTTP request to any server in a bank of identical servers, and any one of them can answer that request. There is state that gets passed back and forth, but it's not tied to any particular server. By contrast, if I have a session object that resides in memory on one particular server, then that service is not stateless. If the server I've been talking to shuts down, then I lose all my state and have to start over. However, if the session object gets saved to a shared database, or a distributed cache like memcached, then no one server has my information. Any server in the bank can handle my requests. My first request can go to one server, and my next request can go to another server. If the server I just talked to crashes and goes away, then I can keep working, because the service is "stateless", meaning it's not holding a special copy of any state information. To answer your question: putting information into cookies is one way to implement a stateless service. It's pushing the state out of the service and back to the client, and the client is responsible for sending it in with each request. If one of my servers crash, that's OK, because you still have your cookie. So in the context of stateless web services, putting data into cookies is one way to make sure that no particular server has the information for a particular client. Cookies are a way to move session state off the server. The client can send that cookie to any service in a bank of servers, and everything will work. ... Note that "stateless" does not mean "no state" ;) Unless you're just trying to warm up your CPU, every application deals with state. The point of "statelessness" is keeping dedicated state information off your servers is so you can make important guarantees about scalability and reliability. Maybe a better term for "statelessness" would have been "anonymity", or "clone-ish-ness" or something like that. ... One last thought; I've had to address the authorization cookie in the context of REST before. The short answer is this: the authentication / authorization process is stateful, because there are specific steps you have to walk through in order. But pushing that information into a cookie, or into a distributed cache meets the desired result of keeping your services stateless. Again, the client state goes off the servers and into the cookies. So a RESTful service can use cookies to pass authorization artifacts and still be stateless. |
||||
|
|
