Paul,
Thank you very much for the valuable information.
I am planning to design the application with two types of resources: public, and secure.
The public URLs will be permanent and bookmarkable. So, "everyone" can have access to this info. In addition, search engines can find them and index them properly. In the other hand the secure resources will be "transitory" as you said, and will require authentication. This will be used for data manipulation and naturally, out of access of "everyone" and the search engines.
Thanks again
-Sami
Date: Mon, 14 Apr 2008 08:59:22 +0200From: Paul.Sandoz_at_Sun.COMTo: users_at_jersey.dev.java.netSubject: Re: Authetication + RESTful
On Apr 11, 2008, at 6:35 PM, Alireza Sami wrote:
Hi Paul, Thanks to both of you! So, let me double check this. Based on what Christian quoted, I could have the session id in the URL (e.g.
http://host/{user}/info/{session_id}) and have the client remember this id during the session lifecycle. Is that correct?
Yes, and when the client is finished with the session it could DELETE it (or the session could just time out if it has not been used for a while). This technique is commonly used for transactions, ticketing or reliable POSTing scenarios.
I don't recall it being used for logging in type scenarios, i guess it depends on what you want to do, but if you want to keep your URLs permanent then using a session id could be problematic because such URIs cannot necessarily be bookmarked, as by their nature such URLs may be transitory. If you can avoid a session ID and instead rely on HTTP authentication then user-based URLs can be reliably bookmarked whether authenticated or not.
Paul.
Thanks again,-Sami
> Date: Fri, 11 Apr 2008 12:08:41 +0200> From: Paul.Sandoz@Sun.COM> To: users@jersey.dev.java.net> Subject: Re: Authetication + RESTful> > Hi Sami,> > Christian, thanks, i was going to do the same :-)> > For user specific information one can utilize user specific URIs i.e. > make the user information resource state and of course ensure that only > correctly authenticated clients have access to those resources.> > For example say you want a page that displays user specific information > and general information together. If the client goes to the general > information uri:> > http://host/info> > and the client is authenticated it could get redirected to:> > http://host/{user}/info> > otherwise the client gets the representation from the first URI. A user > who goes to "http://host/{user}/info" and is not authenticated could get > redirected to "http://host/info".> > One could also use a query parameter for the user and the approach would > still be valid.> > Does that help?> > Paul.> > Christian wrote:> > Hi Alireza,> > > > I don't think there is nothing wrong with using authentication in your > > rest service.> > Just take a look at a mail of Paul from yesterday :> > > > > > I know one of the key principles of REST is that your> > service should be stateless but its a fact of life that sometimes you> > have to store state.> > > > > > This is a common misconception :-) the stateless constraint is about > > *communication*, from Roy's thesis [1]:> > > > We next add a constraint to the client-server interaction:> > communication must be stateless in nature, as in the> > client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3),> > such that each request from client to server must contain all of the> > information necessary to understand the request, and cannot take> > advantage of any stored context on the server. Session state is> > therefore kept entirely on the client.> > > > ...> > > > Like most architectural choices, the stateless constraint reflects a> > design trade-off. The disadvantage is that it may decrease network> > performance by increasing the repetitive data (per-interaction> > overhead) sent in a series of requests, since that data cannot be left> > on the server in a shared context. In addition, placing the> > application state on the client-side reduces the server's control over> > consistent application behavior, since the application becomes> > dependent on the correct implementation of semantics across multiple> > client versions.> > > > I recommend reading section 4.5 of RESTful Web services book:> > > > Statelessness means that every HTTP request happens in complete> > isolation. When the client makes an HTTP request, it includes all> > information necessary for the server to fulfill that request. The> > server never relies on information from previous requests. If that> > information was important, the client would have sent it again in this> > request.> > > > More practically, consider statelessness in terms of addressability.> > Addressability says that every interesting piece of information the> > server can provide should be exposed as a resource, and given its own> > URI. Statelessness says that the possible states of the server are> > also resources, and should be given their own URIs. The client should> > not have to coax the server into a certain state to make it receptive> > to a certain request.> > > > > > > > > > 2008/4/10, Alireza Sami <sami2box@hotmail.com > > <mailto:sami2box@hotmail.com>>:> > > > Hi,> > > > I am a new member of this group. We are trying to develop a set> > of RESTful services for our application.> > > > In the definition of RESTful it is mentioned that RESTful is a> > protocol which is:> > > > - Client-server> > - *Stateless> > *- Cacheable> > - Layered> > > > Please correct me if I am wrong. My understanding is that, if I> > create a RESTful service, it should not return different results for> > different users because there is nothing like a Session object in> > the REST world.> > > > Now, if I support Authentication and/or Authorization for my> > service, I would have different results for different clients which> > is in fact against the fundamentals of this protocol. So, the> > question is that, how we should handle security without violating> > the essential rules of the REST?> > > > Your help is greatly appreciated.> > > > Thank you,> > -Sami> > > > > > ------------------------------------------------------------------------> > Get in touch in an instant. Get Windows Live Messenger now.> > <http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008>> > > > > > -- > | ? + ? = To question> ----------------\> Paul Sandoz> x38109> +33-4-76188109> > ---------------------------------------------------------------------> To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net> For additional commands, e-mail: users-help@jersey.dev.java.net>
More immediate than e-mail? Get instant access with Windows Live Messenger.
_________________________________________________________________
Get in touch in an instant. Get Windows Live Messenger now.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008