RE: What to do about sessions?
Hi Matt, For tracking purpose, we already have a RFE entered to support Google Accounts in our GAE edition: http://restlet.tigris.org/issues/show_bug.cgi?id=779 Any contribution welcome ;) Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com/ http://www.noelios.com De : Matt Kennedy [mailto:stinkym...@gmail.com] Envoyé : mardi 20 avril 2010 18:24 À : discuss@restlet.tigris.org Objet : Re: What to do about sessions? Dj, I'm glad you asked this. I've really lucked out so far and have always worked in an environment that uses client certificates for authentication. The identity of the user is established on every single connection, and I never have to worry about it. But in the near future, I'm going to have to solve the same problem that you're looking at now. You make some astute observations, HTTP_BASIC is only safe over HTTPS, which is very limiting, especially when deploying to GAE. HTTP_DIGEST has some poorly understood compatibility problems with different HTTP clients, furthermore, it isn't what GAE uses natively. It seems that for the GAE edition in particular it would be nice to have an Authenticator that could integrate with the GAE APIs. I'm sure if it isn't done by the time I have to tackle that project that I'll wind up writing one. Does the restlet team have any specific advice for creating a subclass of Authenticator that can get the Google account identity? Specifically a way to use a restlet to write the login example given on this link: http://code.google.com/appengine/docs/java/users/overview.html -Matt On Apr 20, 2010, at 11:37 AM, dj wrote: Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590 591 dsMessageId=2590591 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603377
RE: What to do about sessions?
Hi Marc, Version 2.0 of the Restlet API now has full provision for asynchronous call processing on both client-side and server-side. We are also working on an enhanced default connector for version 2.1 (part of the org.restlet.jar file) that will leverage non-blocking NIO to offer better scalability for scenarios needing thousands of concurrent clients per JVM. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Marc Larue [mailto:m...@rupy.se] Envoyé : jeudi 22 avril 2010 21:27 À : discuss@restlet.tigris.org Objet : Re: What to do about sessions? Well, I wrote my own NIO application server, so yes on both accounts! Polling is not an option, I need to support thousands of concurrent clients per hardware. http://rupy.googlecode.com /m On Thu, 22 Apr 2010, Tal Liron wrote: It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau
Re: What to do about sessions?
It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592758
Re: What to do about sessions?
Well, I wrote my own NIO application server, so yes on both accounts! Polling is not an option, I need to support thousands of concurrent clients per hardware. http://rupy.googlecode.com /m On Thu, 22 Apr 2010, Tal Liron wrote: It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592758
RE: Re: What to do about sessions?
Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291
RE: Re: What to do about sessions?
I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738
Re: Re: What to do about sessions?
REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591774
Re: What to do about sessions?
Hi Marc, So what does REST say about bandwidth, it's not a problem? If you use proxies to cache data, than you not waste, but save bandwith. That's a (or the?) reason that sessions are not allowed. If you have state on the server, than the cache / proxy can't know whats the server state is (for exactly the same request as one minute before). REST services are definitely chatty. REST chats intelligent things like cache information, to allow save bandwith in the future. SOAP is also chatty, but it speak a lot of filler words (tags for soap-header, tags for soap-bosy, tag for the error code and so on). And it uses XML, what is bandwith waste in itself, because it sends a lot of tags double (at start and end of the tag). With REST you could transfer JSON, which does not need double tags. BTW: The best SOAP coup in relation to this is HTTP over SOAP over HTTP (Web Service Resource Transfer, http://www.w3.org/Submission/WSRT/). The most efficent transfer is, if you need to encode the data you want to transfer into an XML node (e.g. to base64, because it contains non printable characters; HTTP directly allows 8 bit) especially when compared to SOAP webservices that might perform N operations in one shot. You could also design your web services to perform multiple operations in one shot: * Get multiple objects: Design a sub collection with the IDs you want * POST multiple objects: send an array of objects (e.g. in XML or JSON). best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591847
Re: Re: What to do about sessions?
REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936
Re: Re: What to do about sessions?
Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue m...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952
Re: What to do about sessions?
Hi dj, session are strictly forbidden in REST, because the scalability advantage of restful applications will get lost, because caches wont work. For details see the dissertation of Roy Fielding, the founder of the REST architecture style, espacially chapter 5 (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). Because restful application is not supposed to support sessions (as you wrote), they are not uspported in Restlet. The restful way is to use HTTP autentication. You just need to use a Guard in your Restlet server deployment, e.g. with HTTP-Basic as authentication scheme. The other things do Restlet and the browser for you, but I can't say if the Google App support it. With a browser (e.g. Firefox or IE) it works. best regards Stephan ___ NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit! http://produkte.web.de/go/02/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590531
RE: What to do about sessions?
Hello, as said Stephan, servlets sessions are not supported. If a user logs in, I want to remember that they're still logged in when they switch between pages, so they don't have to keep re-authenticating. There is no magic. If you have a look at each request issued from the browser, you will see that there is one piece of information that contains the session id (either the cookies header or the url) = each request is somewhat authenticated. When your browser allows cookies, the browser is in charge to generate correct request. In the case your browser does not allow cookies, the servlet container is in charge to generate right urls. Web browsers are also able to authenticate each request using real authentication based on HTTP_BASIC (coupled with https, that's better) or HTTP_DIGEST. The browser is able to ask your credentials, negotiate with the server and authenticate each requests. So, based on this browser feature (generation of requests with correct cookies values or correct basic or digest values), you can set up authentication on server side using subclasses of the Authenticator class. the aim of an authenticator is to parse the request and check that the request is sent by a known and verified user. The Restlet framework provides a ChallengeAuthenticator class that handles HTTP_BASIC and HTTP_DIGEST challenge schemes. There is no Authenticator based on cookies, but it should not be difficult to cope with it. Please note that Authorization is a second phase where the question to answer is : Is this user able to send this request to this resource? The Restlet provides another feature for that : the Authorizer class. Have a look at this page, especially at the sample code at the bottom. It should help you (http://wiki.restlet.org/docs_2.0/13-restlet/46-restlet.html) Feel free to ask for more details. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590610
RE: Re: What to do about sessions?
Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591
Re: What to do about sessions?
Dj, I'm glad you asked this. I've really lucked out so far and have always worked in an environment that uses client certificates for authentication. The identity of the user is established on every single connection, and I never have to worry about it. But in the near future, I'm going to have to solve the same problem that you're looking at now. You make some astute observations, HTTP_BASIC is only safe over HTTPS, which is very limiting, especially when deploying to GAE. HTTP_DIGEST has some poorly understood compatibility problems with different HTTP clients, furthermore, it isn't what GAE uses natively. It seems that for the GAE edition in particular it would be nice to have an Authenticator that could integrate with the GAE APIs. I'm sure if it isn't done by the time I have to tackle that project that I'll wind up writing one. Does the restlet team have any specific advice for creating a subclass of Authenticator that can get the Google account identity? Specifically a way to use a restlet to write the login example given on this link: http://code.google.com/appengine/docs/java/users/overview.html -Matt On Apr 20, 2010, at 11:37 AM, dj wrote: Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590628
