shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tauren Mills <yowza...@gmail.com>
Subject Re: Integration with RESTful framework
Date Tue, 24 Aug 2010 00:31:07 GMT
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 <tamas@cservenak.net>

> Hi Tauren,
>
> we decided to be completely stateless on server side, and we do expect user
> auth for _every_ REST call.
>
> ~t~
>
>

Mime
View raw message