There have been a few messages recently about Shiro and Jersey that prompted me to resurrect this old related thread.
My application currently has some wicket pages for login, logout, account creation, and a few other things. It also uses a rememberme cookie for authentication. Once you are logged in, there is a section of the application that is entirely a single page javascript application. This JS app uses ajax calls to a RESTful jersey service hosted on the same server. The cookie works fine to authenticate for the jersey services as well. The problem is that I'd like to move my API from http://mysite.com/api to http://api.mysite.com/. If I do this, I won't be able to use the cookie auth anymore. Plus, as Tamas suggested below, it is probably best to be stateless on the server side and expect the user to auth for every REST call. Lastly, I intend to open up the API in the future, and I'm not sure relying on cookies is the best technique. So, I'm just trying to wrap my head around authenticating with every REST call. What are good methods of doing this? Does this mean you pass a username and password as query parameters or in post data? I don't necessarily want my JS app to have to ask for and store the user's password (they already authenticated in the wicket app), nor do I like sending passwords in the clear like this: http://localhost:8080/services/helloworld?user=tauren&password=silly I've just started looking into the ways that others such as twitter, facebook, amazon, etc do this. So I'm reading up on OAuth and other techniques. The Shiro issue tracker has an feature request for OAuth, but it doesn't seem like it is a very high priority. I've also seen that many services issue an API public/private key that an application would use, which is an approach I might use down the road. I'd also like to support OpenID, Facebook Connect (or whatever they call it now), etc. At the moment I haven't yet grokked it all, so please let me know if I'm going down the wrong path! Currently, my API is in total flux and hasn't been opened up. It only needs to be usable by my own webapp for now, it doesn't need to be publicly accessible to other applications. But in the near future, parts of it will be opened up. I'll need to support JSONP at that point too. My goal is to have my RESTful URLs return different information depending upon who is accessing them. If the request is not from an authenticated user, then some URLs will return publicly available information only. Some URLs will return no data or an error if you are not logged in. If you are logged in, then you can request things about yourself. And if you are logged in and are a user with additional administrative privileges, then you can request information about others that you have the right to see. But I can see problems with this approach too, so it isn't set in stone yet. Any advice or insights on how to proceed would be extremely helpful! Without OAuth support, I'm unclear on the approaches that other are taking. It seems like a common enough use case that there must be others doing the same thing. Are there some good resources or open source tools I should be looking into? Thanks, Tauren 2010/1/21 Tamás Cservenák <[email protected]> > Hi Tauren, > > we decided to be completely stateless on server side, and we do expect user > auth for _every_ REST call. > > ~t~ > >
