Re: Questions about the Prohibition of String Subclasses in responses

[Eric Wong <normalperson@yhbt.net>]

Eric Wong <normalperson@yhbt.net> wrote:
> Michael Koziarski <koziarski@gmail.com> wrote:
> > Our XSS safe responses will fail this test because they return an
> > instance of ActionView::SafeBuffer which is a subclass of String.  We
> > use a subclass so that we can make all the concat and append
> > operations escape their arguments.

What's the overhead of metadef-ing #concat/#append each String response
on an individual basis vs subclassing?  That could be an option...

Also (not knowing much about Rails or view internals), would it be
possible to make the response an Array-like object and then make all
concats/appends work on the Array-like object instead of the String-like
object?

  class SafeBuffer < Array

    def <<(string)
      super(escape(string))
    end

    ...

  end

And then probably do a #join when responding for performance reasons:

  [ status, headers, [ safe_buffer.join('') ] ]

> > What's the rationale for preventing me from sending a subclass of
> > string?
> 
> Not speaking for anyone else here, but this may break C extensions at
> this point.  It was probably done this way to make extensions easier to
> implement.  The core Ruby IO functions all call rb_obj_as_string() to
> convert their arguments to strings, but some extensions out there may
> not[1].
> 
> [1] *my* C extensions are safe against this, of course :)

But I just read the patch attached to LH ticket #78 and that relaxes
the Hash type check, too.  I actually depend on that being a real
Hash in at least C one extension :x

I'll of course update that extension for the new spec if I need to :>

-- 
Eric Wong