Skip to main content

Simulating Social Login with OmniAuth

08-06-14 Mike Yockey

If you need to fake social logins for testing your Rails app, then Mike’s got the OmniAuth method for you.

Adding a social login to your Rails app is a cinch with OmniAuth, and with the rise of frameworks like Ember and Angular, that Rails app is more and more likely to be an API. Previous apps might have had a sophisticated suite of acceptance tests that drive a browser, but now you need to simulate API calls. RSpec supports this kind of interaction through request specs, but there is no browser, so interactive logins are out. Outlined below are two ways around this with OmniAuth—and why I prefer one over the other.

The Developer Strategy

OmniAuth calls its different authentication methods “strategies,” and out of the box it includes one called “developer,” which, when accessed through a browser, presents the user with a form asking for name and email. It has no external dependencies and can be accessed through a browser to speed up feedback while developing your app. You could use this strategy to authenticate your acceptance test sessions, which looks something like this:

def login
    auth_params = { name: 'Test', email: 'test@example.com' }
    post '/auth/developer/callback', auth_params
end

It posts that name and email address to the authentication callback URI. It works, but there are two issues that I see. First, you probably don’t need a POST route for your callback if you’re using some kind of social login (Twitter, Facebook, GitHub, etc), so this route is exclusively for testing. Second, the developer strategy provided by OmniAuth isn’t what you’d use in production, so it isn’t a true end-to-end test. It would be nice if we could use the code we wrote to handle production logins for our test. We can do that with OmniAuth’s mocks, though.

Mock Authentication

Here’s another example using Mock Authentication with Twitter as our auth source:

OmniAuth.config.test_mode = true
def login
    OmniAuth.config.add_mock(:twitter, { uid: '12345' })
    get '/auth/twitter'
    request.env['omniauth.env'] = OmniAuth.config.mock_auth[:twitter]
    get '/auth/twitter/callback'
end

When we put OmniAuth into test mode on the first line, it will use an internal hash for its authentication data rather than calling out to the integrated service. You can then feed OmniAuth data describing all your authentication scenarios. If you plan to support multiple authentication sources, you can parameterize this method to support that as well:

OmniAuth.config.test_mode = true
def login(mock_login)
    strategy = mock_login[:strategy]
    OmniAuth.config.add_mock(strategy.to_sym, mock_login[:data])
    get "/auth/#{strategy.to_s}"
    request.env['omniauth.env'] = OmniAuth.config.mock_auth[strategy.to_sym]
    get "/auth/#{strategy.to_s}/callback"
end

Example...​

login_data = {
    strategy: 'twitter',
    data: {
        uid: '12345'
    }
}
login(login_data)

Using this to iterate through each authentication strategy you support makes it easy to add or change scenarios just by creating new data. You can add tests for missing data, changes to data structure, or recently discovered failure modes without redefining your tests.

The Robustness Principle

I want to stress that I’m not advocating for testing the behavior of third-party APIs. Rather, I’m advocating for the robustness principle when relying on them. Be liberal in what you accept, conservative in what you return. You must be able to respond to how they change, and having good tests means higher confidence that your application stays secure.

Related Content

See Everything In

Want to talk about how we can work together?

Katie can help

A portrait of Vice President of Business Development, Katie Jennings.

Katie Jennings

Vice President of Business Development