5

I want to manage Sessions with client apps of my Restful WCF Service. Client app can be a J2me application or a .NET application.

What is the recommended way of maintaining sessions in RESTFUL WCF service?

Idea is to recognize that the request is coming from an already authenticated client.

Kunal
  • 1,913
  • 6
  • 29
  • 45

2 Answers2

6

This question may be useful to you: Best Practices for securing a REST API / web service

I think they restful thing to do here is to send the user credentials on each request if you can do that in a way that is transparent to the user and doesn't compromise the credentials. If you can't do that, cookies for the sole purpose of maintaining client identity have become a common concession among developers of restful services. Just don't go storing anything else with the cookie.

Community
  • 1
  • 1
stinkymatt
  • 1,658
  • 11
  • 14
3

REST defines that the interaction is stateless, no client state is maintained on the server so you are looking to move away from a RESTful interface.

I cannot imagine a situation where you would want to maintain client state on a server that's providing WCF services. I think you need to look at your architecture as you are possibly about to cause yourself a lot of technical debt.

Lazarus
  • 41,906
  • 4
  • 43
  • 54
  • My service will be open for Mobile applications and standard asp.net applications and in future some flex and silverlight.My Service also has a method for authenticating the user.I have several other methods in the WCF as well but once authenticated I don't want user credentials to be sent again for each request. I thought adding cookie to headers might solve this.As you said, this is against the principle of using REST, can you recommend the other good ways for maintaining a user identity with each request. – Kunal Dec 09 '10 at 13:50
  • 3
    @Kunal : I agree with @stinkymatt above, the approach is to send the credentials with every request. That said, unless you are using the inherent protocol authentication (i.e. HTTP auth) then you are comparing the supplied credentials against a backing store. If you then generate a Session ID to pass back you are likely to hold that in the same backing store. When the next request arrives you will compare the token against the backing store to see if the user is authenticated... exactly the same as the original authentication request so you only add work in creating and storing the ID. – Lazarus Dec 10 '10 at 08:51