From jabowery at technicalpursuit.com Thu May 4 20:22:37 2006 From: jabowery at technicalpursuit.com (James Bowery) Date: Thu, 04 May 2006 17:22:37 -0700 Subject: [Restful-rails-general] rake db:migrate generator? Message-ID: <445A9ACD.9020704@technicalpursuit.com> I went through the excellent tutorial at: http://www.xml.com/pub/a/2006/04/19/rest-on-rails.html and set up a couple of servers with RESTful Rails. It works great. Thanks for this plugin. It's just what the TIBET(tm) project needed at the right time. (see http://www.technicalpursuit.com and Scott Shattuck's presentation at http://www.theajaxexperience.com/speaker_view.jsp?speakerId=913) |Something that occurs to me from a DYY perspective is that perhaps the: rake db:migrate| should include, or be included in something to generate all the code in the tutorial. This of course would make the most sense if people are doing a Client/SOA (SaaS) application (as is our intent). Are there any plans for this or something like it? From pic at superfluo.org Sat May 13 04:57:31 2006 From: pic at superfluo.org (Nicola Piccinini) Date: Sat, 13 May 2006 10:57:31 +0200 Subject: [Restful-rails-general] authentication howto Message-ID: <44659F7B.4000506@superfluo.org> Hi list, I'm putting on trial the restful rails plugin and it works pretty well. Now I'd want to add the authentication for methods that modify the resources but I can't figure out how to do it. Could anyone point me to the right direction, please? Thanks in advance. -- Nicola Piccinini -- http://superfluo.org From pic at superfluo.org Wed May 24 19:39:10 2006 From: pic at superfluo.org (Nicola Piccinini) Date: Thu, 25 May 2006 01:39:10 +0200 Subject: [Restful-rails-general] experiments with prototype.js and restful-rails plugin Message-ID: <4474EE9E.8040908@superfluo.org> Hello. I'm using the latest revision of restful-rail plugin (revision number 20). I'm trying to talk with the (restful) server in an AJAX way, using the prototype Ajax.Request object in a browser (for the moment I'm testing with mozilla on linux and IE 6 on win me). I've done a few of experiments with the plugin and I like to share the results. Apparently PUT and DELETE methods aren't supported by prototype (version 1.4 and 1.5.0 rc0). So we have two possibilities: 1. tunneling them in a param called "method". 2. "patching" prototype, Restful-rails plugin supports tunneling very well but, anyway, this approach has, imho, a drawback: having the request a parameter, its content type becomes "application/x-www-form-urlencoded" (or "multipart/form-data") and this disables the automatic action of ActionController::Base.param_parsers. In other words: it is no longer possible to pass a xml document in the request body and to have it parsed in the params[:name] object (of course one could manually parse the xml but it's less clean). Luckily "patching" prototype isn't difficult, it requires to add few lines of code, so I decided to go in this way but the workaround would need to be tested on many other platform. Another problem that I noticed with prototype is with the "Accept" header, see: http://www.ruby-forum.com/topic/66607 Unfortunately nobody hasn't answered yet. Some oddities: 1. in IE a 204 status causes an exception in XMLHttrequest.send if the request is synchronous as you can verify with a test similar to the following: xmlhttp = createXmlHttp(); // note that it's synchronous xmlhttp.open("PUT", "/tests/rest_responder/test_204_no_content", false); try { xmlhttp.send("something :-)"); } catch (e) { debug(dump(e)); } The problem disappear with asynchronous request or with other result status (for example 200). Anyone else has noticed it? 2. if you return a content from an head request (I know, that isn't much orthodox) in mozilla it is cut away while in IE it is preserved. This isn't important but it's curious. I didn't understand if the difference depend on how the request is formed or in how the response is treated (more probably the second one) Any comment is highly appreciated, thanks, best regards. -- Nicola Piccinini -- http://superfluo.org From pic at superfluo.org Wed May 24 19:40:34 2006 From: pic at superfluo.org (Nicola Piccinini) Date: Thu, 25 May 2006 01:40:34 +0200 Subject: [Restful-rails-general] authentication and conditions object Message-ID: <4474EEF2.9010203@superfluo.org> > If you want to restrict access to a specific method, then a different > approach is needed. You need to delay asking for authentication > information until the last possible moment, and authorize/authenticate > the user IF the request > method matches the method you want to "protect". I don't have a > clean way > of handling this sort of scenario, [...] > I have a few ideas on how to deal with it that would need to test out > before recommending them. did you make some progress on this topic? In my opinion it's an important feature. I'm a Ruby/Rails newbie and restful-rails plugin is pure magic! Anyway I'm starting to comprehend how it works so if I could help in some way, let me know. Another mysterious component of the plugin is the conditions object. Is there a document that explains its role and importance (that I only guess)? In particular, from a practical point of view, is there something to take into consideration when you mix it with the pagination of collections? Many thanks. -- Nicola Piccinini -- http://superfluo.org From dan.kubb at autopilotmarketing.com Tue May 30 02:03:27 2006 From: dan.kubb at autopilotmarketing.com (Dan Kubb) Date: Mon, 29 May 2006 23:03:27 -0700 Subject: [Restful-rails-general] authentication and conditions object In-Reply-To: <4474EEF2.9010203@superfluo.org> References: <4474EEF2.9010203@superfluo.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nicola, >> If you want to restrict access to a specific method, then a different >> approach is needed. You need to delay asking for authentication >> information until the last possible moment, and authorize/ >> authenticate >> the user IF the request >> method matches the method you want to "protect". I don't have a >> clean way >> of handling this sort of scenario, [...] >> I have a few ideas on how to deal with it that would need to test >> out >> before recommending them. > > did you make some progress on this topic? > In my opinion it's an important feature. I haven't personally made any progress on it, not because I don't agree that its an important feature (it is), its just that I haven't personally needed the feature yet. I don't believe in trying to solve problems that I don't have yet -- the theoretical solution usually doesn't work in practice. Besides access control is application specific much of the time, so what works for me won't necessarily work for you. The mechanics of Basic and Digest authentication are well understood, and relatively easy to implement, but how it hooks into the back-end is the hard part, and usually specific to the application. I'm not entirely sure there's a one size fits all solution to this -- just look at all the authentication plugins for rails in general. > I'm a Ruby/Rails newbie and restful-rails plugin is pure magic! > Anyway I'm starting to comprehend how it works so if I could help in > some way, let me know. With the above as a caveat, the general approach I *think* would work is to extend the before_filter class method in ActionController::Filters::ClassMethods so that you can specify the HTTP method as a condition to running the filter. This would allow syntax like the following: class Book < ActionController::Base before_filter :authentication, :only => :collection, :method => [ :post ] before_filter :authentication, :only => :by_id, :method => [ :put, :delete ] resource :collection do |r| r.post do # handle an HTTP POST to the collection resource end end resource :by_id do |r| r.put do # handle an HTTP PUT to the by_id resource end r.delete do # handle an HTTP DELETE to the by_id resource end end private def authentication # perform Basic or Digest authentication; comparing the username and # password in the HTTP headers against a user in your database end end > Another mysterious component of the plugin is the conditions > object. Is > there a document that explains its role and importance (that I only > guess)? > In particular, from a practical point of view, is there something to > take into consideration when you mix it with the pagination of > collections? The condition object is something that gathers together all the models that you're going to use in your view, either displaying data from the model, or using a value in the model object to display different content to the user. When the view is rendered, the condition object will help generate the ETag and Last-Modified headers for the response. On subsequent requests, where clients supply thee If-* conditional headers, the condition object can "short circuit" the request and notify the client if the server state hasn't changed. This results in much higher responsiveness for web applications, since the view rendering step can be skipped on the server, and there is almost no data transfered between the server and client -- in effect the client is instructed to use the previous response it already has in its cache. Do a google search for "Conditional GET" and you'll see different uses of this. In my opinion its one of the most under-used, but valuable feature of standard HTTP. I honestly don't know why everyone who develops web apps doesn't use it. - -- Thanks, Dan __________________________________________________________________ Dan Kubb Autopilot Marketing Inc. Email: dan.kubb at autopilotmarketing.com Phone: 1 (604) 820-0212 Web: http://autopilotmarketing.com/ vCard: http://autopilotmarketing.com/~dan.kubb/vcard __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEe+Av4DfZD7OEWk0RAuX6AJ9+nDx9yT/9C3VtbpIqkGjqZobAYQCcD1mG Dpt/pEu1C/IRpR90zSvIOuA= =z/68 -----END PGP SIGNATURE----- From dan.kubb at autopilotmarketing.com Tue May 30 02:20:44 2006 From: dan.kubb at autopilotmarketing.com (Dan Kubb) Date: Mon, 29 May 2006 23:20:44 -0700 Subject: [Restful-rails-general] experiments with prototype.js and restful-rails plugin In-Reply-To: <4474EE9E.8040908@superfluo.org> References: <4474EE9E.8040908@superfluo.org> Message-ID: <75A3E21C-4493-4EC5-8A4B-D6623261CD45@autopilotmarketing.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nicola, Unfortunately, I haven't don't much AJAX development with RESTful Rails itself yet, so there's not alot I can contribute I do encourage you to do some experimentation though, REST and AJAX can complement each other well. > Apparently PUT and DELETE methods aren't supported by prototype > (version > 1.4 and 1.5.0 rc0). So we have two possibilities: > 1. tunneling them in a param called "method". > 2. "patching" prototype, > > Restful-rails plugin supports tunneling very well but, anyway, this > approach has, imho, a drawback: having the request a parameter, its > content type becomes "application/x-www-form-urlencoded" (or > "multipart/form-data") and this disables the automatic action of > ActionController::Base.param_parsers. In other words: it is no longer > possible to pass a xml document in the request body and to have it > parsed in the params[:name] object (of course one could manually parse > the xml but it's less clean). Tunneling is only a hack for supporting web browsers that are limited by the HTML spec to just using GET and POST. For AJAX apps you should be able to send any method you wish (barring browser bugs I don't know about). Tunneling was a feature I added reluctantly, simply to support standard web browsers with the same API as special purpose clients and AJAX applications. There's no plans to extend the method tunneling feature to support content types besides application/x-www-form-urlencoded or multipart/form-data. I would discourage method tunneling otherwise. > Luckily "patching" prototype isn't difficult, it requires to add few > lines of code, so I decided to go in this way but the workaround would > need to be tested on many other platform. Patching of Prototype is the route I would suggest, and supplying those patches to the authors. > Another problem that I noticed with prototype is with the "Accept" > header, see: http://www.ruby-forum.com/topic/66607 I can't comment on this specifically, but I'm surprised there's no public method that allows you to overwrite the standard HTTP headers that are sent with each request. > 2. if you return a content from an head request (I know, that isn't > much > orthodox) in mozilla it is cut away while in IE it is preserved. This > isn't important but it's curious. I didn't understand if the > difference > depend on how the request is formed or in how the response is treated > (more probably the second one) While you can do this, many web servers will silently discard any content you return in response to a HEAD request and not send it to the web browser. IMHO, this is the proper way to handle it because you want all the same after_filters to be applied to the response in case the Content-Length is modified by one of them. The response to a HEAD request should have *identical* headers to a GET request for the same URI. The only exception is variable headers like Date that changes depending on the time of the response. - -- Thanks, Dan __________________________________________________________________ Dan Kubb Autopilot Marketing Inc. Email: dan.kubb at autopilotmarketing.com Phone: 1 (604) 820-0212 Web: http://autopilotmarketing.com/ vCard: http://autopilotmarketing.com/~dan.kubb/vcard __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEe+Q84DfZD7OEWk0RAvIPAJ4mCU0eOTPtbrfleCzL1wRXUU3OjgCdH82e KCXxWyN/6Sl4TTanPCaERtM= =znDD -----END PGP SIGNATURE-----