Abusing bang methods in Ruby for fun and profit

Ruby has a quasi-convention of taking a method, slightly modifying its behavior, and denoting it with a trailing exclaimation mark, e.g. #select becomes #select!. Sometimes these methods raise an error, modify the receiver in place, or return nil on no-op, or do some combination of these, or something else entirely. Such methods are collectively referred to as “bang” methods, and there’s no hard-and-fast rule for what makes them special—just that they are “more dangerous” than their non-bang counterparts.

Today I’d like to write about bang methods that modify their receivers in place and return nil on no-op, and how you can improve performance in Ruby applications by (ab)using them to reduce object churn in hot paths.

Continue reading

Whole-home audio redux with Amazon and Google

Image courtesy of Monoprice

Hey, it was 2002, and it worked.

I’ve been experimenting with whole-home audio since college. I bought a 100′ stereo cable and ran it from my roommate’s bedroom all the way down to the front room so we could have music playing on both floors of our four-person townhome. I remember price-shopping multi-zone amplifiers when I didn’t have two nickels to rub together. It seemed the height of luxury to be able to listen to the same song no matter where you were in the house.

Continue reading

Session-only cookie corruption in Ruby web apps

Rack and Rails have a cookie monster.

Browsers place limits on the number and size of cookies present for a domain or in a response. If you exceed these limits, Bad Things can happen. Rack and Rails try to prevent this in the obvious cases, but this post describes what they get wrong in their current implementations. We’ll also review the potential impact of—and how you can mitigate—this type of issue in your Ruby web apps.

This information is most relevant for web apps that transmit session cookies that contain the encoded contents of the entire session hash—not just the session ID. In other words, a cookie-only session. For example, Rack::Session::Cookie with Marshal or JSON, Rails’ default ActionDispatch::Session::CookieStore, or an implementation of JWT (JSON Web Tokens) that uses a cookie (instead of a dedicated response header) as its transport. The security risks are greatest when cookie-only sessions meet the cookie-truncation behavior of older browsers (and can be compounded when the sessions contain arbitrarily-large data, such as flash messages).

TL;DR: If your Ruby web apps use cookie-only sessions, consider adding Rack::Protection::MaximumCookie to their middleware stacks.

Continue reading

How fanriff.com works, Part I

I thought I’d write about how fanriff.com serves its Ember.js index from its Sinatra.rb API, and how web clients interacts with the back-end once the application is loaded. It started to run a little long so I’ve broken it up into parts. This first chapter will cover some background information on Ember, the fanriff.com web architecture, and how we deploy our Ember index to our stack.

Continue reading

Torii for Ember.js Lightning Talk

The slides for my recent Torii for Ember.js Lightning Talk (it ran a little long, so it was more of a “thunder” talk) are now available to download. They closely follow my post about Ember.js and Torii from September, and indeed the slides link to that post for the code walkthrough. Please let me know in the comments if you have any questions, and of course I’m available to chat in the EmberJS Community Slack team as @mwpmaybe (invite yourself here if you’re not already signed up).

I think there’s a video of my talk, but I understand the quality is not that great. I’ll post it here as soon as possible, assuming it’s not too bad.

Rack::Deflater in Sinatra

“Can I use Rack::Deflater in my Sinatra application?” Yes, absolutely. It’s a piece of Rack middleware and therefore super easy to use:

use Rack::Deflater

Furthermore, the RubyDoc for Rack::Deflater gives a cool little example of how to conditionally enable Rack::Deflater based on the size of the response body:

use Rack::Deflater, :if => lambda {
  |env, status, headers, body| body.length > 512
}

Unfortunately, this doesn’t work in Sinatra, or at least not on Sinatra 1.4.6, Rack 1.6.4, and Ruby 2.2.3. Why? Well, body is (for some reason) an array, so its length is probably zero (nil body) or one. It also occurs to me that we care more about the byte size of the body than its string length; if you think a 513-byte response is worth compressing, 512 characters encoded in UTF-32 (2,048 bytes) certainly is!

Here’s a modified (and code-golfed) version of the above snippet for Sinatra:

use Rack::Deflater, :if => lambda {
  |*, body| body.map(&:bytesize).reduce(0, :+) > 512
}

Happy deflating!

Easy login sessions with Ember.js and Torii

This is an easy and simple session lifecycle solution pattern for Ember.js 1.13/2.0 using Torii 0.6.0 that I’d like to share. Ember is a framework for building single-page web applications (SPAs) in JavaScript and HTMLBars. Torii abstracts authentication (authn) and authorization (authz) services in Ember and gives you powerful hooks into authn providers (social media login, e.g. Facebook or Twitter, or your company’s internal directory service) and customizable authz adapters (i.e. your application’s backend). It can inject the session object returned by your API into routes and controllers, and protect routes that require authorization.

Continue reading