Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

May 25, 2010

Third Time’s the Charm?

Rails got updated to 2.3.6, 2.3.7, and 2.3.8, within the space of 48 hours. On the theory that the “Third time’s the charm.” I decided to update Instiki for 2.3.8, this morning.

Running the Instiki test suite, immediately pointed to some problems.

Under Ruby 1.9.x, I got a slew of errors that looked like:

 test_accept_header_html(ApplicationTest):
 ArgumentError: invalid byte sequence in US-ASCII
     /Users/distler/instiki/vendor/rails/activesupport/lib/active_support/core_ext/object/blank.rb:68:in `=~'
     /Users/distler/instiki/vendor/rails/activesupport/lib/active_support/core_ext/object/blank.rb:68:in `!~'
     /Users/distler/instiki/vendor/rails/activesupport/lib/active_support/core_ext/object/blank.rb:68:in `blank?'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/response.rb:201:in `nonempty_ok_response?'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/response.rb:187:in `handle_conditional_get!'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/response.rb:140:in `prepare!'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/base.rb:540:in `send_response'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/base.rb:534:in `process'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/filters.rb:606:in `process_with_filters'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/test_process.rb:567:in `process_with_test'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/test_process.rb:447:in `process'
     /Users/distler/instiki/vendor/rails/actionpack/lib/action_controller/test_process.rb:398:in `get'
     test/functional/application_test.rb:48:in `test_accept_header_html'
     /usr/local/lib/ruby/gems/1.9.1/gems/mocha-0.9.8/lib/mocha/integration/mini_test/version_131_and_above.rb:26:in `run'
     /Users/distler/instiki/vendor/rails/activesupport/lib/active_support/testing/setup_and_teardown.rb:24:in `run'

US-ASCII ?? Well, it turns out that activesupport/lib/active_support/core_ext/object/blank.rb defines an extension to the String class, without being sufficiently (at least, for Ruby 1.9) picky about encodings. The solution was to add an encoding-aware monkey-patch to lib/stringsupport.rb.

class String

  ...

  def blank?
    self.dup.as_bytes !~ /\S/
  end

end

Similarly, I had some problems with ERB templates

 test_search_FFFD_in_query(WikiControllerTest):
 ActionView::TemplateError: incompatible character encodings: UTF-8 and US-ASCII
     On line #70 of app/views/layouts/default.rhtml

     67:     <div class="errorExplanation"><%= escape_preserving_linefeeds(@error || flash[:error]) %></div>
     68: <%- end -%>
     69: 
     70: <%= @content_for_layout %>
     71: 
     72: <%- if @show_footer -%>
     73:     <div id="footer">

Again, this was a matter of Rails trying to guess the encoding of the ERB templates, and guessing wrong (US-ASCII). One solution would be to go through all the ERB templates, and set the encoding manually. I decided on a simpler alternative of a monkey patch, overriding the guessing code in actionpack/lib/action_view/template_handlers/erb.rb, and forcing the encoding to ‘UTF-8’.

The other annoyance was that, apparently, X-Sendfile no longer works in development mode, which broke my tests to … umh … check that X-Sendfile works.

Finally, it seems that the “Rails 3.0” XSS Protection is enabled by default. Which meant fixing various helper methods, to mark their output as html_safe.

Other than that, my morning was OK …

Hope this helps someone else spend their day more productively.

Update:

As Sam points out in the comments, in response to this post the Rails team have modified Rails 2.3.x to ensure that the XSS Protection really is disabled by default. If you’re upgrading a Rails app from 2.3.5, and want to save yourself some trouble, you might want to download that patch (or wait for 2.3.9).

Being a masochist, I went the other direction and installed the rails_xss plugin to see what else would break.

Posted by distler at May 25, 2010 2:02 PM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/2218



7 Comments & 1 Trackback

Re: Third Time’s the Charm?

Does this commit help?

Posted by: Sam Ruby on May 25, 2010 4:44 PM | Permalink | Reply to this

Re: Third Time’s the Charm?

Does this commit help?

The one from half an hour ago?

Possibly.

In a way, though, I’m kinda happy to start having to keep track of which strings Rails 3.x will consider “safe.” It will make the eventual transition to Rails 3 easier.

The only surprise was having to think about this now, even though 2.3.8 purportedly doesn’t enable XSS Protection by default.

Posted by: Jacques Distler on May 25, 2010 5:03 PM | Permalink | PGP Sig | Reply to this

Re: Third Time’s the Charm?

Yes, that commit was a result of my pointing the Rails Core team at your blog post. The basic idea is that you shouldn’t have to worry. Unless you want to, of course, and if you do, you simply install the full xss_plugin.

Posted by: Sam Ruby on May 25, 2010 8:12 PM | Permalink | Reply to this

Re: Third Time’s the Charm?

Yes, that commit was a result of my pointing the Rails Core team at your blog post.

Wow! That is impressive turnaround, then.

The basic idea is that you shouldn’t have to worry.

Indeed. That was my impression.

Which was why (after all the XSS Protection-induced grief of the past few days) I was surprised to see it active when I upgraded Instiki from 2.3.5 to 2.3.8.

Unless you want to, of course, and if you do, you simply install the full xss_plugin.

Little steps for little feet.

I had intended to explore the xss_plugin after upgrading Instiki to 2.3.8, and making sure that everything else was working.

Fortunately, there wasn’t too much to fix …

Posted by: Jacques Distler on May 25, 2010 9:34 PM | Permalink | PGP Sig | Reply to this
Read the post Third Time's the Charm?
Weblog: Musings
Excerpt: Tribulations updating Instiki for Rails 2.3.8.
Tracked: May 26, 2010 10:49 AM

Problems running Instiki on Rails 2.3.8

Professor,

Apologies if this is not the right place, but I have been having Instiki installation-related trouble for some time.

I have been happily using Instiki in my previous Gentoo Linux box for a few months.

When I installed it in my recent gentoo installation, and I start Instiki, I get

$ ./instiki –daemon
=> Booting WEBrick
=> Rails 2.3.8 application starting on http://0.0.0.0:2500

So far so good.

However, when I point the browser to http://localhost:2500/, I get the following error:
Firefox can’t establish a connection to the server at localhost:2500

And yes, the internet is working.

I noticed that the older (successful) installation was a Rails 2.3.5 installation.

Any suggestions?

I installed instiki and itex2MML using the bzr installation instructions.

Thanks!

PS: Some details on the ruby installation :

dev-lang/ruby-1.8.7_p249

and with - sign in a USE flag indicating not included in the compilation

USE=”berkdb gdbm ipv6 ssl -debug -doc -emacs -examples -rubytests -socks5 -threads -tk -xemacs”

Also, my /etc/hosts is:

# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost machinename
#::1 localhost

Posted by: AnInstikiUser on June 15, 2010 6:32 PM | Permalink | Reply to this

Re: Problems running Instiki on Rails 2.3.8

I would suggest starting Instiki without the “--daemon” flag, so that you can see what’s going on with it.

I don’t know much about gentoo, but you might try going through the installation instructions to see whether there’s some prerequisite that’s not present.

Posted by: Jacques Distler on June 15, 2010 8:45 PM | Permalink | PGP Sig | Reply to this

Re: Problems running Instiki on Rails 2.3.8

Professor,

Thanks for the tip. My problem has been resolved. I am not sure if the following was a key step in the resolution of my problem:

#gem install sqlite3-ruby

but everything worked well soon after I did that. In any case, all is well.

It is nice to be able to use such a wonderful (and powerful) tool. Many thanks for your efforts!

Posted by: AnInstikiUser on June 16, 2010 5:36 PM | Permalink | Reply to this

Post a New Comment