Re: [Rails-core] Default <%= to use the h (html safe) method.
There was a discussion about this on the main rails list a week or two ago...
Basic conclusions that I cam away with were...
Since most of the problematic data would be coming from the database, it
might be easiest to set up activerecord to escape text by default. This
escaping could be turned off in the model definition if necessary.
class Model < AR::Base
acts_as_unescaped :attribute1, :attribute2
end
method_missing could also be set up to recognize things like
"#{attribute}_unsafe" to return the unescaped code. This has the bonus
effect of self documenting the code and making it obvious when the
unescaped value is being used.
For example, which code fragment below is returning unescaped text?
<%= item.name_unsafe %>
or
<%= item.name %>
Changing ERb will probably lead to enormous headaches at this point.
The key thing is to change the default behavior to secure rather than
unsecure. If you fail to unescape when the default in secure, you just
break the app. If you fail to escape when the default is unsecure, you
expose your data.
A broken app will be obvious from your tests and can be fixed, an
unsecure one probably won't, and you won't know there is a problem until
its too late.
Sure it will impose a performance hit, but this should really be a
secondary concern to security.
_Kevin
--
Posted with http://DevLists.com. Sign up and save your time!
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
I haven't personally suffered the agony of magic quotes, but the problem seems to have been that it didn't unescape well and that it would break methods that were not expecting escaped text. My contention is that those methods were already broken because they were unsecure and/or couldn't handle escaped text. Using the autoescaping features just made it obvious. I also agree with David that this particular technology is well suited to a plugin. In fact there already is a plugin that almost does the job (except that you have to turn on the security instead of turning it off). I suppose it would also be good practice to write unit tests that feed methods escaped vs. unescaped input to make sure your code is robust. _Kevin On Tuesday, February 14, 2006, at 9:22 PM, Kyle Maxwell wrote: >I can't help but think that by Rails 2.0, we'll think of this >potential "feature" the same way as the PHP community thinks of magic >quotes. > >-kyle > >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core > -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
On Wednesday, February 15, 2006, at 2:50 PM, Tom Ward wrote: >This is a bad idea. It assumes data from ActiveRecord models only >ever displayed on the web. This ignores email templates, logging, etc >from within web apps, not to mention applications using ActiveRecord >outside the web. The idea of the plugin would be to make it easy to turn off the behavior if you found it necessary to do so. In my view, if escaping the text by default causes problems then you at least have to think about turning it off. Besides, sneaky code can be a problem in places other than rendered html. Such a system where you have to manually opt out of the control is better because it guards against mistakes. Sure, a good programmer shouldn't need such a system, but mistakes will be made. I would rather have the mistake cause an obvious failure than go silently undetected. _Kevin -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
Yeah, I'm fiddling with this now. Turns out to be a bit tricker than I thought, but should be doable. _Kevin On Wednesday, February 15, 2006, at 12:31 PM, David Heinemeier Hansson wrote: >I think the time has come for less talk and more code. Make a plugin >that implements this. Use it for a month. If you still like it and >find the trade-offs to be reasonable, ask other people to give it a >swing. Once there's a critical mass of acceptance, let's discuss how >we can use those learnings to possibly improve the default approach in >Rails. >-- >David Heinemeier Hansson >http://www.loudthinking.com -- Broadcasting Brain >http://www.basecamphq.com -- Online project management >http://www.backpackit.com -- Personal information manager >http://www.rubyonrails.com -- Web-application framework >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
I have setup a rubyforge project called 'autoescape' that includes a quick plugin that implements the ability to automatically escape text columns from the database. If you feel adventurous, all you need to do is drop it in your plugin directory. http://rubyforge.org/projects/autoescape/ or svn://rubyforge.org//var/svn/autoescape If you wish to get the raw attribute text, simply use 'attribute_raw'. You can also make a column raw by default by declaring 'acts_as_raw :column' in the model definition. There are some important limitations to note. Most importantly, it uses the ActiveRecord after_find callback. This means that if you are using this callback already, you will need to call super in your callback routine somewhere or it will not run at all. There is also room for some performance enhancements as well. However, it does work on rail 1.0 (not tested on edge yet). It may also cause unexpected behavior in forms because the form fields will be populated with 'escaped' text by default. This release is intended to be a proof-of-concept version. The goal is to see if it is useful, causes all sorts of unexpected problems, or both. Suggestions for improving the code are welcome. _Kevin On Wednesday, February 15, 2006, at 6:40 PM, Kevin Olbrich wrote: >Yeah, I'm fiddling with this now. >Turns out to be a bit tricker than I thought, but should be doable. > >_Kevin > >On Wednesday, February 15, 2006, at 12:31 PM, David Heinemeier >Hansson wrote: >>I think the time has come for less talk and more code. Make a plugin >>that implements this. Use it for a month. If you still like it and >>find the trade-offs to be reasonable, ask other people to give it a >>swing. Once there's a critical mass of acceptance, let's discuss how >>we can use those learnings to possibly improve the default approach in >>Rails. >>-- >>David Heinemeier Hansson >>http://www.loudthinking.com -- Broadcasting Brain >>http://www.basecamphq.com -- Online project management >>http://www.backpackit.com -- Personal information manager >>http://www.rubyonrails.com -- Web-application framework >>___ >>Rails-core mailing list >>Rails-core@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > > >-- >Posted with http://DevLists.com. Sign up and save your time! >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
Rick, :after_find doesn't exist by default. It only gets called if it is defined. The way I set this up, it defines an 'after_find' callback in ActiveRecord::Base, so other plugins or classes would have to alias the one I defined to get it to work right. I'm tinkering around with some methods to avoid this completely, but I wanted to get something testable out there for people to play with first. _Kevin On Sunday, February 19, 2006, at 3:47 PM, Rick Bradley wrote: >Kevin, >Thanks for the good work putting this together. > >> There are some important limitations to note. Most importantly, >>it uses >> the ActiveRecord after_find callback. This means that if you are using >> this callback already, you will need to call super in your callback >> routine somewhere or it will not run at all. > >Quick question: why not alias the original :after_find so it can be >chained? > >Rick >-- > http://www.rickbradley.comMUPRN: 422 > | know that you're a > random email haiku | target, you should filter your > | power thoroughly. >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
This plugin has been updated a bit. The algorithm is a bit more efficient and the whole thing is simpler and more robust. The update is only available through the subversion repository at the moment. _Kevin On Sunday, February 19, 2006, at 7:25 PM, Kevin Olbrich wrote: >I have setup a rubyforge project called 'autoescape' that includes a >quick plugin that implements the ability to automatically escape text >columns from the database. If you feel adventurous, all you need to do >is drop it in your plugin directory. > >http://rubyforge.org/projects/autoescape/ > >or > >svn://rubyforge.org//var/svn/autoescape > -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Plugins and testing
I'd just like to clarify the load behavior of plugins before I go opening new tickets. I developed a couple of plugins that add some functionality to activerecord, however, when I run unit tests (and the console for that matter), the plugin does not appear to load. None of the additional functionality is available. Is this intended behavior, or is it a bug? _Kevin -- Posted with http://DevLists.com. Sign up and save your time! ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] before_find
Just curious... Why isn't there a 'before_find' callback for ActiveRecord? _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] before_find
Well, what I'm thinking of would be more like a class-level before_find. I'd like to intercept the options going into 'find', and pre-process them on a model-per-model basis, and then pass that along to 'find'. The general idea is to give models an ability to restrict which users can access individual records. To make it clean, I'd like to build it into the normal find process. So, yeah, a object level before_find doesn't make sense, but a class level one does. Sure, I could write a plugin to do this, but it would essentially be adding a before_find call manually. On Saturday, April 22, 2006, at 4:49 PM, Rick Olson wrote: >On 4/22/06, Tobias L�tke <[EMAIL PROTECTED]> wrote: >> uh. because the objects are not instanciated/exist before they are >> actually found. Or is this a philosophical question? > >Existential Rails Plugin :) > >Kevin: do you have a use case in mind? Surely anything you want done >before_find can be done before the find call? > >-- >Rick Olson >http://techno-weenie.net >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] before_find
Yeah, I know how to do it that way. I'm just exploring other options. On Saturday, April 22, 2006, at 7:40 PM, Tobias Lütke wrote: >def find(*params) > [..] before find code > super >end > >On 22 Apr 2006 23:09:07 -, Kevin Olbrich ><[EMAIL PROTECTED]> wrote: >> Well, what I'm thinking of would be more like a class-level before_find. >> I'd like to intercept the options going into 'find', and pre-process >> them on a model-per-model basis, and then pass that along to 'find'. >> The general idea is to give models an ability to restrict which users >> can access individual records. To make it clean, I'd like to build it >> into the normal find process. >> >> So, yeah, a object level before_find doesn't make sense, but a class >> level one does. Sure, I could write a plugin to do this, but it would >> essentially be adding a before_find call manually. >> >> On Saturday, April 22, 2006, at 4:49 PM, Rick Olson wrote: >> >On 4/22/06, Tobias L�tke <[EMAIL PROTECTED]> wrote: >> >> uh. because the objects are not instanciated/exist before they are >> >> actually found. Or is this a philosophical question? >> > >> >Existential Rails Plugin :) >> > >> >Kevin: do you have a use case in mind? Surely anything you want done >> >before_find can be done before the find call? >> > >> >-- >> >Rick Olson >> >http://techno-weenie.net >> >___ >> >Rails-core mailing list >> >Rails-core@lists.rubyonrails.org >> >http://lists.rubyonrails.org/mailman/listinfo/rails-core >> >> >> _Kevin >> >> -- >> Posted with http://DevLists.com. Sign up and save your mailbox. >> ___ >> Rails-core mailing list >> Rails-core@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-core >> > > >-- >Tobi >http://shopify.com - modern e-commerce software >http://typo.leetsoft.com - Open source weblog engine >http://blog.leetsoft.com - Technical weblog > >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core > _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] before_find
Nice, that looks very handy for this purpose. On Monday, April 24, 2006, at 11:33 AM, Tim Lucas wrote: >On 23/04/2006, at 3:09 AM, Kevin Olbrich wrote: > >> Yeah, I know how to do it that way. >> I'm just exploring other options. > >The other way to accomplish what you want is to use finder scopes: >http://habtm.com/articles/2006/02/22/nested-with_scope > >-- tim >___ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core _Kevin , -- Posted with http://DevLists.com. Sign up and save your mailbox. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Testing has_many :dependent => :restrict
On Saturday, July 29, 2006, at 1:29 PM, Daniel N wrote:
>On 7/27/06, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
>>
>> On Jul 26, 2006, at 6:06 AM, Daniel N wrote:
>> > I've had a crack at this one and it is as I feared.
>> >
>> > If I define the restrict association first, then the destroy chain
>> > is halted and all is well. But if I have an association where
>> > a :dependent => :destroy is declared before the association
>> > with :restrict then the first association is destroyed before the
>> > destroy chain is halted.
>>
>> You can wrap the destroy method to leapfrog the callback chain.
>>
>> associations.rb, configure_dependency_*
>>
>>case reflection.options[:dependent]
>> when :restrict
>>class_eval <<-end_eval
>> def destroy_with_has_many_#{reflection.name}
>>unless #{reflection.name}.blank?
>> raise DestroyRestricted.new(self, #
>> {reflection.name.inspect})
>>end
>> end
>>
>> alias_method_chain :destroy, "has_many_#{reflection.name}"
>>end_eval
>> # ...
>>end
>>
>>
>> base.rb
>>
>>module ActiveRecord
>> class DestroyRestricted < ActiveRecordError
>>def initialize(model, by)
>> super "#{model.class.name} #{model.id} destroy restricted by
>> #{by}"
>>end
>> end
>>end
>>
>>
>> > I have taken my first real plunge into the rails source and found a
>> > number of places where I thought a transaction might go to prevent
>> > this but to no avail. Actually my head is spinning a bit trying to
>> > put all the pieces of active_record together.
>> >
>> > For this to work I think I need to put a transaction around the
>> > entire destroy chain, but I have no idea how to do this.
>> >
>> > Any pointers anyone could give would be great.
>>
>> destroy and its callbacks are wrapped in a single transaction (see
>> transactions.rb) so you can raise an exception to rollback.
>>
>>
>> example:
>>
>>class ParentController < ApplicationController
>> def destroy
>>@parent.destroy
>>redirect_to parent_url(@parent)
>> rescue ActiveRecord::DestroyRestricted => restricted
>>flash[:error] = restricted.message
>>redirect_to :back
>> end
>>end
>>
>>
>> Best,
>> jeremy
>> ___
>> Rails-core mailing list
>> Rails-core@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>>
>
>Thanx Jeremy. This looks very different to what I had in mind. Lots
>better :)
>
>I'll get into trying to get this to work.
>
>Just a thought tho. By raising an exception, this would put destroy into a
>different category, this should perhaps be destroy! to fit with the other
>methods that raise errors.
>
>Would including an exception into the destory method mean that it would
>break exisitng code? I guess you would only need to use a rescue if you
>have declared a relationship as rectricted. I'll have a go anyway and see
>what ppl think.
>
>Thanx for you help
>
>Cheers
>
>
>___
>Rails-core mailing list
>Rails-core@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
Wouldn't it make sense to have it call a function like 'can_destroy?'
before trying to do the work? Have that function recursively call
itself on all the child objects, and then only return true if all
dependent objects can be destroyed.
If can_destroy? returns false, then... don't destroy it.
It might be a little more robust than relying on exceptions, since it
will test everything before trying to destroy anything.
_Kevin
www.sciwerks.com
--
Posted with http://DevLists.com. Sign up and save your mailbox.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
