7

In a web services, how does the server know which request belongs to which session?

I know that for a web application, the web server inspects the cookie (or the sessonId query parameter in case cookies are disabled) so it knows which session the request is associated with. But for a request that comes from a rest client, how do the server know?

gnat
  • 21,442
  • 29
  • 112
  • 288
dnang
  • 575
  • 3
  • 5
  • 10
  • Why can't you use cookies in RESTful web services? – Florian Margaine Oct 28 '13 at 13:51
  • My guess would be a sessionId send with each request. But also http://en.wikipedia.org/wiki/Device_fingerprint is a possibility (I think not yet used as replacement of as sesionId send by the client) – MrSmith42 Oct 28 '13 at 15:23
  • Thank you, I think I will try using cookie or token headers and see how it works out. – dnang Oct 29 '13 at 13:23

1 Answers1

8

If you really must have session handling in your API then the client would be responsible to handle the session_id and add it to the URL if required. How exactly to handle this would depend on your technology stack. For example Rails defaults to cookies but (if enabled) would also accept a _session_id parameter as part of the URL.

The relevant information normally stored in the cookie together with the session id then must be handled by the server. In Rails you would have to switch session storage from cookie storage to one of the server options like storing it in the database or memcached with the session_id as key.

But you should really think twice if you want to add this feature to your API. Being stateless will keep your API simpler and easier to maintain. If any possible it is preferable to let the client worry about state and send all necessary information with each request. (like using HTTP basic authentication instead of storing a current user in a session).

thorsten müller
  • 12,058
  • 4
  • 49
  • 54
  • 1
    Agreed, after reading about REST I really like the idea of a stateless web-services. But I also saw many tutorials where people favor a token based authentication with the token being expired after a certain amount of time. The rationale is that sending credentials with every request is less secure. So how can I achieve both statelessness and high level of security? – dnang Oct 28 '13 at 14:21
  • In this case HTTPS is most likely your best option. Unless you encrypt your communication there will always be some risk that people can hijack cookies, api-keys or session ids. After all with a token based system they would still be able to steal this specific session. Though they would not gain the password maybe. Still this is not what you want to happen. Anyway, in that case you add a kind of user_session resource that the client "creates" once and which returns your token (stored in your database together with time until it is valid). – thorsten müller Oct 28 '13 at 14:49
  • Yes, I also thought of use HTTPS along with tokens. I heard that HTTPS alone can be broken. – dnang Oct 30 '13 at 13:30
  • @dnhang I'm no expert on this, but I am not aware about any major breaks of HTTPS security (unless maybe some cases where a companies whole certification & DNS servers would have been compromised). In any case it would require far more knowledge and criminal intent than just downloading some packet sniffer by some teenage kid, like say firesheep if this is still a thing. – thorsten müller Oct 30 '13 at 13:51
  • Maybe it's just over-anxiety, but I came across this answer that made me confused (http://stackoverflow.com/a/14907718/2691869). It looks to me the weak point is the CAs, if they are hacked, or if they voluntarily give out cert/private key to 3rd party (e.g. government agency), the encryption in SSL/TLS become useless. Is this practical or just theory? Another risk is on the client side, but I think with Java I'm fine because I've never seen my Java program automatically trust a self-signed certificate. I don't know how the JVM treats the Certificate Revocation List though. – dnang Nov 03 '13 at 01:36
  • @dnhang interesting details, thanks for posting. But if you read closely then three of his four points are risks on the client side that would make people communicate with untrusted sites as used for fishing attacks. This has nothing to do with your communication once correctly established. There is always a risk that malicious people get the user credentials. Either by smart fishing attacks or more primitive calling them and claim to be a service technician. All you can do is secure the actual transmission against listeners (especially when used in open wifi) – thorsten müller Nov 03 '13 at 07:15