Rails core - Feb 2006 - Default <%= to use the h (html safe) method.

I was just reading a blog post, about how PHP applications lack so much as
far as security goes, and it got me thinking that Rails should come default
secure, and you should have to force it to be less secure.

On that note, I came up with the idea of having <%= default to use the XSS
safe (or soon to be) h method.

So, <%=h var %> and <%= var %> are really the same. 

Any thoughts?

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On 2/12/06, Nathaniel S. H. Brown <nshb@inimit.com>
wrote:
> I was just reading a blog post, about how PHP applications lack so much as
> far as security goes, and it got me thinking that Rails should come default
> secure, and you should have to force it to be less secure.
>
> On that note, I came up with the idea of having <%= default to use the
XSS
> safe (or soon to be) h method.
>
> So, <%=h var %> and <%= var %> are really the same.
>
> Any thoughts?
Unftortunately this would break existing applications which rely on
the original behaviour.  So even if we thought it was something we''d
like to do, it''d have to wait until rails 2.0.   It''s also a
little
counter-intuitive, I don''t know that I like the idea.

--
Cheers

Koz

+1

Would reduce clutter on the templates. It''s pretty annoying to have to
remember to put them in, and even more annoying to get tickets from QA
about XSS.

On 2/11/06, Nathaniel S. H. Brown <nshb@inimit.com>
wrote:
> I was just reading a blog post, about how PHP applications lack so much as
> far as security goes, and it got me thinking that Rails should come default
> secure, and you should have to force it to be less secure.
>
> On that note, I came up with the idea of having <%= default to use the
XSS
> safe (or soon to be) h method.
>
> So, <%=h var %> and <%= var %> are really the same.
>
> Any thoughts?
>
> -Nb
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Nathaniel S. H. Brown                           http://nshb.net
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>

Good point.

We could always make it a configuration option for 1.0?

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
> -----Original Message-----
> From: rails-core-bounces@lists.rubyonrails.org 
> [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf 
> Of Michael Koziarski
> Sent: February 11, 2006 8:31 PM
> To: rails-core@lists.rubyonrails.org
> Subject: Re: [Rails-core] Default <%= to use the h (html safe) method.
> 
> On 2/12/06, Nathaniel S. H. Brown <nshb@inimit.com> wrote:
> > I was just reading a blog post, about how PHP applications lack so 
> > much as far as security goes, and it got me thinking that 
> Rails should 
> > come default secure, and you should have to force it to be 
> less secure.
> >
> > On that note, I came up with the idea of having <%= default 
> to use the 
> > XSS safe (or soon to be) h method.
> >
> > So, <%=h var %> and <%= var %> are really the same.
> >
> > Any thoughts?
> 
> Unftortunately this would break existing applications which 
> rely on the original behaviour.  So even if we thought it was 
> something we''d
> like to do, it''d have to wait until rails 2.0.   It''s
also a little
> counter-intuitive, I don''t know that I like the idea.
> 
> --
> Cheers
> 
> Koz
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>

huh? that would break url_for, link_to, textilize, markdown and every
single other helper which outputs html tags. I use the h helper in
like 3 different places in shopify, thats definitely the exception.
> On that note, I came up with the idea of having <%= default to use the
XSS
> safe (or soon to be) h method.
--
Tobi
http://shopify.com       - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

All of those helper functions would obviously need to be changed so that
they work with the default <%=h methods. The <%= tag could be smart enough
to realize what it is parsing, and if it''s a helper method, to skip it.

It''s an abstract idea. If it''s worth investigating, we can
look at how to
implement it, on a more specific level. Especially what implications it has,
as you have mentioned.

As far as I am concerned, these are minor details which can be ironed out
with a bit of creativity.

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
> -----Original Message-----
> From: rails-core-bounces@lists.rubyonrails.org 
> [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf 
> Of Tobias Luetke
> Sent: February 11, 2006 9:04 PM
> To: rails-core@lists.rubyonrails.org
> Subject: Re: [Rails-core] Default <%= to use the h (html safe) method.
> 
> huh? that would break url_for, link_to, textilize, markdown 
> and every single other helper which outputs html tags. I use 
> the h helper in like 3 different places in shopify, thats 
> definitely the exception.
> 
> > On that note, I came up with the idea of having <%= default 
> to use the 
> > XSS safe (or soon to be) h method.
> 
> --
> 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
>

On 2/12/06, Nathaniel S. H. Brown <nshb@inimit.com>
wrote:
> All of those helper functions would obviously need to be changed so that
> they work with the default <%=h methods. The <%= tag could be smart
enough
> to realize what it is parsing, and if it''s a helper method, to
skip it.
>
> It''s an abstract idea. If it''s worth investigating, we
can look at how to
> implement it, on a more specific level. Especially what implications it
has,
> as you have mentioned.
>
> As far as I am concerned, these are minor details which can be ironed out
> with a bit of creativity.
I don''t actually think that''s possible.    Whatever new output
link_to
returned, would just be the new target for XSS guys.


--
Cheers

Koz

Nathaniel S. H. Brown wrote:
> I was just reading a blog post, about how PHP applications lack so much as
> far as security goes, and it got me thinking that Rails should come default
> secure, and you should have to force it to be less secure.
>
> On that note, I came up with the idea of having <%= default to use the
XSS
> safe (or soon to be) h method.
>
> So, <%=h var %> and <%= var %> are really the same. 
>
> Any thoughts?
>   
Several.

* Introducing this will break existing applications, which already make 
use of h, since h isn''t idempotent.

* If <%= expr %> already produces valid html (or a html fragment like 
"</p>", which becomes valid through the page context), applying
h to
expr will produce garbage.

* And of course, it would severely hurt performance.

So -10 from me.

-- stefan


-- 
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml

As I said before, I (or we, for whoever is in support) can solve the minor
details, and provide solutions with a little bit of creativity. I am of the
opinion that if you see points such as the ones you mentioned, you may also
be able to see how to fix them, if you so desire. I have some suggestions.
> * Introducing this will break existing applications, which 
> already make use of h, since h isn''t idempotent.
As I said previously, this could be available as a configuration option,
negating your remark about breaking existing applications. You would have to
explicitly choose to break your own application. And where would that leave
you? Providing the option to enable the XSS security for those who do choose
for it. When enabled, the h function would be wiser at detecting what it is
that it''s encoding.

One idea is to have a safe list of tags and html code which can be verified,
such as those found on the 
> * If <%= expr %> already produces valid html (or a html 
> fragment like "</p>", which becomes valid through the page 
> context), applying h to expr will produce garbage.
Again, this would be solved with the configuration option. But even if it
was default in 2.0 as core, we could consider utilizing the non-xss method,
something like <%=r for raw, which would provide the ability to switch the
default to a raw version of the string, instead of encoding it.

Another idea might be to have a .xss extension, which defaults to using the
<%=h method on all print statements, or does a scan of the document for all
XSS vulnerabilities we are able to detect. This may even be a bit overkill,
but maybe not?

<%=r ''<p>This is raw html'' %>, would be an elegant
way to solve the
do-not-touch-this-html issue, but would require people to reverse their
opinions of what <%= does.
> * And of course, it would severely hurt performance.
I wouldn''t mind seeing a benchmark of <%=
''<p>test</p> %> vs. <%=h
''<p>test</p>'' %> to back this statement up.
Understandably, the h method
does do a bit more. But how much more? And what about caching?
> So -10 from me.
Hmm..

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On 2/12/06, Nathaniel S. H. Brown <nshb@inimit.com>
wrote:
> As I said before, I (or we, for whoever is in support) can solve the minor
> details, and provide solutions with a little bit of creativity. I am of the
> opinion that if you see points such as the ones you mentioned, you may also
> be able to see how to fix them, if you so desire. I have some suggestions.
Nathaniel,  I don''t think that this is a solvable problem.  What would
you propose the output of link_to and other helpers be?  Why can''t
malicious users encode their text in such a way.

Given the complexity involved in solving these problems, and the
performance cost of escaping everything (it''s considerable).  This
isn''t something we''re going to change.

--
Cheers

Koz

> On 2/12/06, Nathaniel S. H. Brown <nshb@inimit.com> wrote:
> > As I said before, I (or we, for whoever is in support) can 
> solve the 
> > minor details, and provide solutions with a little bit of 
> creativity. 
> > I am of the opinion that if you see points such as the ones you 
> > mentioned, you may also be able to see how to fix them, if 
> you so desire. I have some suggestions.
> 
> Nathaniel,  I don''t think that this is a solvable problem.  
> What would you propose the output of link_to and other 
> helpers be?  Why can''t malicious users encode their text in 
> such a way.
One idea might be to have any helper method to have a wrapper around it,
which is cleaned after using the <%= method. Such an example,

Such as link_to(:controller => ''xss'', :action =>
''safe'') in it''s raw state
appends and prepends the {{SAFE}} and {{/SAFE}} string, which it''s
contents
are ignored by the <%= method. At the conclusion of execution of the
<%tag, a simple text.gsub(/{{(/?)SAFE}}/, '''') tag is
performed and the safe
tags are stripped.

<%= ''<xss hack here>'' + link_to(:controller =>
''xss'', :action => ''safe'') +
''</xss hack here>'' %>

This would clean the xss, and ignore the link_to.
> Given the complexity involved in solving these problems, and 
> the performance cost of escaping everything (it''s 
> considerable).  This isn''t something we''re going to
change.
I was under the impression that Rails is an open source project, I thought?
I didn''t intend to presume that you would be the one fixing it. I was
simply
asking for suggestions (or opinions?).

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> One idea might be to have any helper method to have a wrapper around it,
> which is cleaned after using the <%= method. Such an example,
>
> Such as link_to(:controller => ''xss'', :action =>
''safe'') in it''s raw state
> appends and prepends the {{SAFE}} and {{/SAFE}} string, which it''s
contents
> are ignored by the <%= method. At the conclusion of execution of the
<%> tag, a simple text.gsub(/{{(/?)SAFE}}/, '''') tag is
performed and the safe
> tags are stripped.
>
> <%= ''<xss hack here>'' + link_to(:controller
=> ''xss'', :action => ''safe'') +
> ''</xss hack here>'' %>
>
> This would clean the xss, and ignore the link_to.
So I''ll just send the following into your XSS variables.

{{SAFE}}<script
type="text/javascript">steal_all_your_stuff()</script>{{/SAFE}}

If we do something like this, XSS protection is impossible.
> I was under the impression that Rails is an open source project, I thought?
> I didn''t intend to presume that you would be the one fixing it. I
was simply
> asking for suggestions (or opinions?).
Rails is an open source project,  but patches don''t get applied
without review by one of us on the core team.  I''ve discussed it with
a few of the other guys and we''re not going to change this.

The other option is for you to release a plugin which implements this
kind of behaviour.  But given the performance problems it''ll
introduce, and the fact it makes security more difficult, I don''t
think it would be a good idea.
--
Cheers

Koz

Nathaniel S. H. Brown wrote:
> As I said before, I (or we, for whoever is in support) can solve the minor
> details, and provide solutions with a little bit of creativity. I am of the
> opinion that if you see points such as the ones you mentioned, you may also
> be able to see how to fix them, if you so desire. I have some suggestions.
>
>   
>> * Introducing this will break existing applications, which 
>> already make use of h, since h isn''t idempotent.
>>     
>
> As I said previously, this could be available as a configuration option,
> negating your remark about breaking existing applications. You would have
to
> explicitly choose to break your own application. And where would that leave
> you? Providing the option to enable the XSS security for those who do
choose
> for it. When enabled, the h function would be wiser at detecting what it is
> that it''s encoding.
>
> One idea is to have a safe list of tags and html code which can be
verified,
> such as those found on the 
>   
In order to implement this properly you''d need to do a HTML parse 
(including javascript!) of the string passed to h and validate that. 
Obviously, parsing HTML is overkill for performance. And it''s still
open
whether the question "should something be escaped here" is decidable
at
all. I believe it isn''t.
>> * And of course, it would severely hurt performance.
>>     
>
> I wouldn''t mind seeing a benchmark of <%=
''<p>test</p> %> vs. <%=h
> ''<p>test</p>'' %> to back this statement
up. Understandably, the h method
> does do a bit more. But how much more? And what about caching?
>   
Nice try, but the proof obligation w.r.t. implementability and 
performance is on the proposer of the change.

Why don''t you go ahead and implement a plugin that changes <%= 
semantics? Not that I would recommend it or give it a good chance of 
success in the community, but it''s up to you if you want to put effort 
into this.

-- stefan

-- 
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml



_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

@ nathaniel

I am agains doing h on all <%=, but why not just write a plugin? see how 
it works? sometimes it takes a extra step to convince people.

Stefan Kaes wrote:
> Nathaniel S. H. Brown wrote:
>> As I said before, I (or we, for whoever is in support) can solve the
minor
>> details, and provide solutions with a little bit of creativity. I am of
the
>> opinion that if you see points such as the ones you mentioned, you may
also
>> be able to see how to fix them, if you so desire. I have some
suggestions.
>>
>>   
>>> * Introducing this will break existing applications, which 
>>> already make use of h, since h isn''t idempotent.
>>>     
>>
>> As I said previously, this could be available as a configuration
option,
>> negating your remark about breaking existing applications. You would
have to
>> explicitly choose to break your own application. And where would that
leave
>> you? Providing the option to enable the XSS security for those who do
choose
>> for it. When enabled, the h function would be wiser at detecting what
it is
>> that it''s encoding.
>>
>> One idea is to have a safe list of tags and html code which can be
verified,
>> such as those found on the 
>>   
> In order to implement this properly you''d need to do a HTML parse 
> (including javascript!) of the string passed to h and validate that. 
> Obviously, parsing HTML is overkill for performance. And it''s
still
> open whether the question "should something be escaped here" is 
> decidable at all. I believe it isn''t.
>>> * And of course, it would severely hurt performance.
>>>     
>>
>> I wouldn''t mind seeing a benchmark of <%=
''<p>test</p> %> vs. <%=h
>> ''<p>test</p>'' %> to back this
statement up. Understandably, the h method
>> does do a bit more. But how much more? And what about caching?
>>   
> Nice try, but the proof obligation w.r.t. implementability and 
> performance is on the proposer of the change.
>
> Why don''t you go ahead and implement a plugin that changes <%= 
> semantics? Not that I would recommend it or give it a good chance of 
> success in the community, but it''s up to you if you want to put
effort
> into this.
>
> -- stefan
>
> -- 
> For rails performance tuning, see: http://railsexpress.de/blog
> Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>

Hi !

2006/2/12, Tobias Luetke
<tobias.luetke@gmail.com>:
> huh? that would break url_for, link_to, textilize, markdown and every
> single other helper which outputs html tags. I use the h helper in
> like 3 different places in shopify, thats definitely the exception.
Am I reading this right ?  3 places ?  I use it on every list screen I
have.  I don't trust the admin interfaces anymore than I would trust a
public comments form.  So, I even HTML escape product names and codes.

Could you explain which places you do and don't use HTML escape ? 
Maybe I'm too paranoid ?

Thanks !
--
François Beausoleil
http://blog.teksol.info/

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Allow me to chime in with the fact that this would work poorly for
applications that actually allow user-inputted HTML, such as Basecamp.
I would not want to do <%=unescape_h on all of my outputs to negate
the effects of this.

But as others have suggested, plugins are a great way of changing
Rails in ways specific to your environment. If you feel that =h is a
major burden, then rock on with that plugin. It''s a great way of
sharing extensions that are not suited for "most people, most of the
time".
--
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

In one case two years ago (not a Rails app but it would have been) the
QA team verifying the app we built had some sort of automated tool
that checked for XSS vulnerabilities to the extreme and forced us to
address each and every one of them, despite the fact that it was an
internal-facing webapp. Major FPITA.

Having a config setting which addressed XSS all at once (if possible
and performant, which I''m not claiming it is) would be interesting and
potentially useful. I don''t think Nathaniel should be slapped down for
suggesting it, and I do believe he was slapped down a bit.

A different approach might be to leave <%= alone and introduce a
different ERB operator that is XSS safe, perhaps <%:  ... my point is
there are probably lots of different ways to attack this problem.

Are there more important issues to address? Probably.

Obie

On 2/12/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> Hi !
>
> 2006/2/12, Tobias Luetke <tobias.luetke@gmail.com>:
> > huh? that would break url_for, link_to, textilize, markdown and every
> > single other helper which outputs html tags. I use the h helper in
> > like 3 different places in shopify, thats definitely the exception.
>
> Am I reading this right ?  3 places ?  I use it on every list screen I
> have.  I don''t trust the admin interfaces anymore than I would
trust a
> public comments form.  So, I even HTML escape product names and codes.
>
> Could you explain which places you do and don''t use HTML escape ?
> Maybe I''m too paranoid ?
>
> Thanks !
> --
> François Beausoleil
> http://blog.teksol.info/
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>

By escaping the html your customers input you potentially disable a
lot of cool features.

For example we use html to make links in todo list items in basecamp
all the time. Couldn''t do that if it was escaped.

On 2/12/06, Francois Beausoleil <francois.beausoleil@gmail.com> wrote:
> Am I reading this right ?  3 places ?  I use it on every list screen I
> have.  I don''t trust the admin interfaces anymore than I would
trust a
> public comments form.  So, I even HTML escape product names and codes.

--
Tobi
http://shopify.com       - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

2006/2/12, Tobias Luetke
<tobias.luetke@gmail.com>:
> By escaping the html your customers input you potentially disable a
> lot of cool features.
>
> For example we use html to make links in todo list items in basecamp
> all the time. Couldn't do that if it was escaped.
Isn't Textile quite suited to this sort of task ?  Wouldn't it be safer
?

I don't personnaly use Basecamp, but if I remember correctly, many
people view the pages, so what prevents a bad user from doing:

<a href="some link" onclick="do potentially bad thing
here">Click me !</a>

???

Thanks !
--
François Beausoleil
http://blog.teksol.info/

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Then that user is a jerk and is kicked out of basecamp.
> I don''t personnaly use Basecamp, but if I remember correctly, many
> people view the pages, so what prevents a bad user from doing:
>
> <a href="some link" onclick="do potentially bad thing
here">Click me !</a>
--
Tobi
http://shopify.com       - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

> A different approach might be to leave <%= alone and introduce a
> different ERB operator that is XSS safe, perhaps <%:  ... my point is
> there are probably lots of different ways to attack this problem.
How is that operator different from <%=h my_string %>?

Here''s a suggestion: If you use html_escape more than regular output,
bind your TextMate (or whatever editor) hotkey for ERb outputs to
include the h by default. That''d be a very Less Software approach to
doing the same.
> Are there more important issues to address? Probably.
In my humble opinion, labeling this as though it would rid the world
of XSS is simplistic. It''s a noble goal to be pursuing that, but the
interesting parts around that is how you deal with XSS when you WANT
to allow some HTML.

In any case, I applaud anyone who wishes to make it easier for people
to deal with XSS. And I can see on this thread that the slaps
Nathaniel got could indeed be misconstrued as being about whether XSS
is important to deal with or not. That''s not as helpful as simply
providing the reasons why _this_ particular suggestion is not going to
work.

So -1 on the specifics, +1 on the intentions. Keep thinking.
--
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

> Isn''t Textile quite suited to this sort of task ? 
Wouldn''t it be safer ?
It''s suited some times for some of the tasks. But its not a general
purpose replacement for HTML.
> I don''t personnaly use Basecamp, but if I remember correctly, many
> people view the pages, so what prevents a bad user from doing:
>
> <a href="some link" onclick="do potentially bad thing
here">Click me !</a>
Basecamp is account restricted. You have to be invited and accept the
invitation to become part of a project and see the content. In this
context, the ability of being able to use HTML outweighs the
risk/impact of malicious users (you usually just participate in
projects with people you know).

On a public forum, it''s different. I wouldn''t want to allow
HTML there.
--
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

We did this in OpenACS where I used to contribute, and found it to be  
a really bad idea, only too late.

Variable interpolation in OpenACS is done with @varname@, and to  
avoid the HTML quoting, you have to say @varname;noquote@.

The reasons are the same as stated here:

1) It turns out that quoting is the exception, not the norm

2) It broke so many things that relied on this, that all the lower  
level services had to put ;noquote everywhere.

3) It hurt performance.

I''d also vote -10.

What we should do is encourage people to thing of "<%=h" as a
common
idiom in the "getting started" documentation and examples.

/Lars

On Feb 12, 2006, at 7:50 AM, Stefan Kaes wrote:
> Nathaniel S. H. Brown wrote:
>> I was just reading a blog post, about how PHP applications lack so  
>> much as
>> far as security goes, and it got me thinking that Rails should  
>> come default
>> secure, and you should have to force it to be less secure.
>>
>> On that note, I came up with the idea of having <%= default to use  
>> the XSS
>> safe (or soon to be) h method.
>>
>> So, <%=h var %> and <%= var %> are really the same.
>> Any thoughts?
>>
> Several.
>
> * Introducing this will break existing applications, which already  
> make use of h, since h isn''t idempotent.
>
> * If <%= expr %> already produces valid html (or a html fragment  
> like "</p>", which becomes valid through the page context),
> applying h to expr will produce garbage.
>
> * And of course, it would severely hurt performance.
>
> So -10 from me.
>
> -- stefan
>
>
> -- 
> For rails performance tuning, see: http://railsexpress.de/blog
> Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core

> How is that operator different from <%=h my_string %>?
>
> Here''s a suggestion: If you use html_escape more than regular
output,
> bind your TextMate (or whatever editor) hotkey for ERb outputs to
> include the h by default. That''d be a very Less Software approach
to
> doing the same.

Point taken. I think I''ll actually make a hotkey like that. I always
forget otherwise.

Obie

On 12.2.2006, at 19.18, Francois Beausoleil wrote:
> 2006/2/12, Tobias Luetke <tobias.luetke@gmail.com>:
>> By escaping the html your customers input you potentially disable a
>> lot of cool features.
>>
>> For example we use html to make links in todo list items in basecamp
>> all the time. Couldn''t do that if it was escaped.
>
> Isn''t Textile quite suited to this sort of task ? 
Wouldn''t it be
> safer ?
Textile gets interpreted to html in the input phase in all but the  
most trivial applications. After that, you can''t anymore use the h  
version, because the stuff displayed is stored as html. So we''re now  
talking about output while textile is mainly relevant in input.  
Besides, you can use html tags in default textile, too.

//jarkko

--
Jarkko Laine
http://jlaine.net
http://odesign.fi

This is an interesting idea. It''s certainly easy at the moment to  
forget the h on a field and open yourself  up to XSS attacks.  
Defaulting to h and having a way to get around it would be more  
likely to show up problems in testing rather than in production. On  
the other hand, it may be more trouble than it''s worth. I''ll
reserve
judgement.

On the implementation side, I would think you''d add a
"html_safe?"
attribute to String. Link_to et al could return strings that are  
marked as html_safe, and %= could spit this straight out. (They''d  
also have to look at strings passed in to them and determine whether  
or not to escape them based on their html_safe flags.) Regular  
strings would not be html_safe by default, and would be escaped by % 
=. You could then provide a method to change a given string into its  
html_safe version, and provide a one character abbreviation (similar  
to ''h'') so that you could do <%=s
"<b>whatever</b>" %> when you
needed to.

The other useful thing would be a little ActiveRecord extension so  
that you could mark an attribute of a model object as returning a  
html_safe string, for those times you want to store HTML in the  
database.

Hmm...it''s all a little like string tainting in perl, really. You  
could even go so far as to make, for example, concatenating two  
html_safe strings return another html_safe string, but that''d be a  
lot of work and probably not worth it.

So, the upshot of all that is that thinks like <%= link_to ''A  
link!'', ... %> would still work as they always have, but anytime you
want to put your own html in via %=, you''ll have to mark it as safe.  
That''s reasonably neat and undisruptive I think.

If somebody does implement any of this as a plugin, I''d definitely  
give it a go in our production code.

Cheers,

Pete Yandell

On Sun, Feb 12, 2006 at 11:30:31AM -0600, David Heinemeier Hansson
wrote:
> > I don''t personnaly use Basecamp, but if I remember correctly,
many
> > people view the pages, so what prevents a bad user from doing:
> >
> > <a href="some link" onclick="do potentially bad
thing here">Click me !</a>
> 
> Basecamp is account restricted. You have to be invited and accept the
> invitation to become part of a project and see the content. In this
> context, the ability of being able to use HTML outweighs the
> risk/impact of malicious users (you usually just participate in
> projects with people you know).
> 
> On a public forum, it''s different. I wouldn''t want to
allow HTML there.
Allowing that there are some apps which must not allow _any_ script
injection (e.g. a bank loan system where the first privacy leak is
already a disaster), how about a mix of helpers/features that let one
optimize for local style?  i.e. let coders carve out areas that should
be input escaped, input filtered or output escaped.

Favor seldom-write/many-read performance
 * escape_html :var model method to escape input in model typecasting/wherever;
   use straight <%= foo %> on output

Allow html-rich content
 * safe_html :var model method to filter for a clean (programmable) subset

Be backward compatible
 * add a <%~ foo %> style to ERB, equivalent to <%= h foo %>

I have html filter code (albeit Java) -- I''ll dig it up.  I can write
an erb patch for the Ruby folks.

Thoughts?

-jeremy
_____________________________________________________________________
jeremy wohl ..: http://igmus.org

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!

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

> 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.
I agree. Trying to be too clever about this stuff is a sure fire way to agony.

But hey, don''t let theories spoil the practice. Plugins are great for
trying out disruptive changes like that to see if it fits. And
considering the scale of such a change, there would be no way any of
these ideas would make it in anyway before proving themselves as a
widely used and cherished plugin.

So do get programming.
--
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

I really like the idea of acts_as_secure/unescaped, especially with the
method missing catch as you have mentioned.

<%= model.name_raw %> or <%= model.name %>

Raw is simply a naming preference for me, as name would be the processed
version (secured). 

The discussions so far have shown two very strong sides of opinions towards
the idea of having xss (or even security in general) enabled by default, yet
one point still stands in merit alone. Rails should be secure by default.
PHP has been plagued with never ending hacks on applications built the
language due to the precise reason of it''s default ability for
programmers
to choose to secure their applications, rather than the reverse, which we
are discussing to purposefully choose to turn off the security in the
framework.

For a second, imagine Rails as a framework you have to choose to turn off
the security. Personally, that sounds like an excellent goal in of itself
worth striving for. My initial email I sent with this intent in mind, has
struck a nerve, which seems to be tugged back and forth on semantics and may
even be dismissed by some and definitely disputed by others solely on the
analysis of the finer details. Realizing my goal now, it wasn''t to say
"this
is how it should be done", but rather, "how about we solve the issue
of
security before it becomes a problem". The recommendation towards having
<%output the same content as <%=h seems to have addressed a very important
point, that security should be enabled default.

Backwards compatibility is obviously going to be a serious point to enable
something like this. A few methods of solving this that were suggested:
1. Have a option in config/environment.rb that enables security be default,
or even the level/degree of security you want. Similar to PHP''s error
output
level.
2. Create a new plugin such as acts_as_unescaped for each of the data types
with the ability to have method_missing catches so you can access the
model.name_raw value.
3. Modify ERB to create a new output stream which is secure <%~

The third point, where by the recommendation suggested to change ERB and
support a new style of <%~, instead of <%= would simply break the intent
of
my original goal, but is worth still investigating in it''s own right.
Reason
being, you would have to go out of your way again to secure your sprint. The
default is <%= now, people are used to it, it has become the standard, which
should be enhanced to be the standard which is secure. Your application
should be secure by default, and you choose to print the unsecure version
with such a statement as <%~ model.name %>, to output the same thing as
<%model.name_raw %>.

To summarize Kevin point, the importance of security should not be measured
by the loss of performance, but rather the peace of mind gained knowing
invested knowledge has been converged to make developing on the path of
majority, is safer than treading off on your own. At this point, it is
actually safer to go against the default print statement being <%=.

I read over and over again, key contributors to the community pairing
"PHP"
with the security (or lack there of). You only need to look at an
application like phpBB to see such evidence. This isn''t due to the fact
that
PHP can''t be secured, it simply takes extra resources to really
understand
and realize that certain methods of doing things are not safe, such as how
to avoid SQL injection.

To be honest, it took me up until about a few weeks ago to come across a
posting from someone in the Rails community why <%=h is needed to secure the
output of the user input. I have been developing with rails for some time
now, and I know a few things about XSS, yet still, while I was shifting my
paradigm to Rails, I had simply forgot about encoding my HTML output. The
apps I have written are not blogware, or open to the public so this
wasn''t a
major concern of mine, but it brought up a good point. At what point do we
say, OK, I need to secure my application now. 

Another example to highlight is the :conditions on things such as
model.find. This should always be encoded, and you should have to override
the default to allow direct data insertion.

That said, when finding all records such as this:

Model.find(:all, :conditions => ''this = "'' +
params[:xss] + ''"'')

Should not even be allowed to happen. One method I had found, maybe a month
after getting into Rails, was a post by Robby mentioning how to use hash
marks, like so:

Model.find(:all, :conditions => [''this = :this'', {:this
=> params[:xss]}])

Now, from what I gather that is the secure way of writing a condition, yet
TONS of people I can guarantee have no idea about this, or even the simpler
method without the named using the sprintf method. Either way, security
should be default, and you should have to break off the Rails path to choose
to open up security holes in your application.

- Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
> -----Original Message-----
> From: rails-core-bounces@lists.rubyonrails.org 
> [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf 
> Of Kevin Olbrich
> Sent: February 14, 2006 8:44 PM
> To: rails-core@lists.rubyonrails.org
> Subject: 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
>

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!

> To be honest, it took me up until about a few weeks ago to come  
> across a
> posting from someone in the Rails community why <%=h is needed to  
> secure the
> output of the user input. I have been developing with rails for  
> some time
> now, and I know a few things about XSS, yet still, while I was  
> shifting my
> paradigm to Rails, I had simply forgot about encoding my HTML  
> output. The
> apps I have written are not blogware, or open to the public so this  
> wasn''t a
> major concern of mine, but it brought up a good point. At what  
> point do we
> say, OK, I need to secure my application now.
I find this hard to believe.  I heard about escaping with <%=h on my  
first day on Rails.  Also, I love how escaping has become synonymous  
with "secure", when the issue of security goes far beyond html  
escaping.  For instance, your next point...
>
> Another example to highlight is the :conditions on things such as
> model.find. This should always be encoded, and you should have to  
> override
> the default to allow direct data insertion.
>
> That said, when finding all records such as this:
>
> Model.find(:all, :conditions => ''this = "'' +
params[:xss] + ''"'')
>
> Should not even be allowed to happen. One method I had found, maybe  
> a month
> after getting into Rails, was a post by Robby mentioning how to use  
> hash
> marks, like so:
>
> Model.find(:all, :conditions => [''this = :this'',
{:this => params
> [:xss]}])
>
> Now, from what I gather that is the secure way of writing a  
> condition, yet
> TONS of people I can guarantee have no idea about this, or even the  
> simpler
> method without the named using the sprintf method. Either way,  
> security
> should be default, and you should have to break off the Rails path  
> to choose
> to open up security holes in your application.
>
> - Nb
How could anybody go through the present documentation on rails and  
not come across this?  Have you even read AWDWR?  I can''t even count  
how many times this has been presented to me in my reading on rails.   
Not to mention, if it hadn''t been presented to me, I would have gone  
looking for it.  It should be common knowledge for any database  
developer, whether web related or not, that variables in SQL  
statements should be bound.  If this syntax hadn''t been so accessible  
I would have said, "Ok, so how do I bind variables in Ruby...there  
must be something akin to my old friend the ''?'' character from
the
Perl DBI."

Furthermore, how do you prevent someone from simply concatenating the  
variable into the string?  This would require some sort of pre- 
compile to detect the presence of the concatenation operator in the  
parameter string...and oh yeah, we would need to make sure they  
didn''t use #{} either.  The find method can''t know if the
string was
written explicitly or pieced together from several variables.  This  
is a compilation issue...talk about a performance hit!

There are always going to be newbies, and the newbies need  
information about how to write "safe" code.  Therefore, we must keep  
writing it.  However, if we attempt to restrict the language in such  
a way as to make it impossible to write sloppy code, we''ll end up  
with nothing more than AppleScript for the web...or worse  
yet...HyperCard!  However, anybody with the 2-3 years experience it  
usually takes to get a job without a supervisor breathing down your  
neck while you program will already know this stuff.  If they haven''t  
learned it by now, they''re dangerous and should get out of the
industry.

Don''t tie my hands.  If you''re scared of your own code, write
an
acts_as_diffident plugin.  If this email sounds harsh, you can blame  
it on the fact that I''m hungry, tired, or both... or perhaps
I''m just
right... who knows?


-Derrick Spell

"Perl''s grammar can not be reduced to BNF.
The work of parsing perl is distributed between
yacc, the lexer, smoke and mirrors.''''
-Chaim Frenkel

On 2/15/06, Nathaniel S. H. Brown <nshb@inimit.com>
wrote:
> I really like the idea of acts_as_secure/unescaped, especially with the
> method missing catch as you have mentioned.
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 issue is in output from ERb html templates, that's where it should
be solved.  Any solution shouldn't affect non-web apps, or even web
apps using other templating engines.

As for how it's solved, I agree with the principle of security as
default, but also that there should be no breaking changes before 2.0.
 If we enhance ERb making <%= safe and <%~  dangerous output, the
behaviour should be configured by a flag, defaulting to off before 2.0
and on after.  Perhaps it would also be OK if freshly generated rails
apps had the flag set to true in environment.rb before 2.0.  I'm not
sure.

Finally, I think I prefer <%!= for dangerous output, but does that
look too much like not-equal?

Tom
--
nick: tomafro

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

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!

On 15 Feb 2006 15:39:25 -0000, Kevin Olbrich
<devlists-rails-core@devlists.com> wrote:
>
> 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.
I've no problem making html output secure by default, but ActiveRecord
is the wrong place to do this, even as a plugin.  Many applications
have a wide range of output formats, not just ERb generated html, and
changing ActiveRecord will affect them all.  I should only have to
think about turning escaping off in places where it could have been a
problem in the first place.

Tom Ward
--
nick: tomafro

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

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

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!

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!

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.com    MUPRN: 422
                       |  know that you''re a
   random email haiku  |  target, you should filter your
                       |  power thoroughly.

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.com    MUPRN: 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!

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!