Here’s a quick snippet that we’re using to reindex Solr from our Cucumber features.

“And I reindex assets” helps to ensure that we didn’t leave any cruft around from previous
tests and that we’ve properly indexed our Pickle model.

  Background:
    And I am logged in as an admin user
    And an asset with snowboarding tags: "snowboarding" exists with title: "Snowboarding", alt_text: "Snowboarding", summary: "A summary about snowboards"
    And I reindex assets

  Scenario:  An Editor searches for an asset by title
    When I go to the url: "/assets?q=Snowboarding"
    Then I should see "Snowboarding"

Here’s the actual step

  When /^I reindex (.+)$/ do |model_name|
    model_name.singularize.capitalize.constantize.solr_reindex
  end

Twitter has been completing the migration of third party applications, such as Tweed, to use their new authentication methods. (For more on the authentication details, please see Twitter’s developer docs.)

One result of this change is that the free version of Tweed no longer works. As we have noted in the past, we are no longer supporting the free version of Tweed, so we will not be upgrading it to work with Twitter’s new authentication scheme.

We understand this will frustrate many Tweed users. For a limited time, the paid version of Tweed will be available for $0.99, in all markets. This price change should appear in the App Catalog soon.

Ever wondered how to login as another user within Devise?

Recently we had a feature request that would provide Admins with the ability
to sign is as another user. You could imagine live demonstrations or even production
support calls where you would like to be signed in as another user, yet not
have to ask for or decrypt their current password. After stewing for a bit, we found a
pretty nice solution with Devise.

Here’s the Cucumber feature…

  Feature: Sign in as another user
    As an admin
    I want to sign in as another user

    Scenario: Admin can sign in as another user
      Given I am logged in as an admin user
      And a user: "bob" exists with email: "bob@example.com", password: "password", ...
      When I go to the admin users page
      And I follow the "Sign in as" link for user: "bob"
      Then I should see "Welcome Bob"

The trick was to store the admin info within the rack session.

request.env['rack.session']['devise.remember_admin_user_id']

We decided on using a Rails 3 concern to keep our actual strategy clean.

require 'devise/strategies/base'

module SignInAs
  module Concerns
    module RememberAdmin
      extend ActiveSupport::Concern

      private

      def remember_admin_id
        request.env['rack.session']['devise.remember_admin_user_id']
      end

      def remember_admin_id=(id)
        request.env['rack.session']['devise.remember_admin_user_id'] = id
      end

      def remember_admin_id?
        request.env['rack.session'] && request.env['rack.session']['devise.remember_admin_user_id'].present?
      end

      def clear_remembered_admin_id
        request.env['rack.session']['devise.remember_admin_user_id'] = nil
      end
    end
  end
end

The above really makes writing the Devise strategy fairly easy.

require 'devise/strategies/base'

module SignInAs
  module Devise
    module Strategies
      class FromAdmin < ::Devise::Strategies::Base
        include SignInAs::Concerns::RememberAdmin

        def valid?
          remember_admin_id?
        end

        def authenticate!
          resource = User.find(remember_admin_id)
          if resource
            clear_remembered_admin_id
            success!(resource)
          else
            pass
          end
        end
      end
    end
  end
end

Warden::Strategies.add(:sign_in_as, SignInAs::Devise::Strategies::FromAdmin)

Then we just wire in our new strategy. Last line above.

Lastly, here’s our sign-in-as controller which sets the Devise session variable.

class SignInAsController < ApplicationController
  include SignInAs::Concerns::RememberAdmin

  layout 'admin/application'

  def create
    if can?(:manage, :users)
      self.remember_admin_id = current_user.id
      sign_in :user, User.find(params[:user_id])
    end

    redirect_to '/admin'
  end

end

That’s it, pretty neat and might make for a nice Gem or Devise addition.

If you’ve recently forked the ey-cloud-recipes on GitHub and then had issues
managing and deploying multiple projects with disparate dependencies using the
single forked gem, then we have a solution that has worked well on a recent project.

We’ve tucked the cookbooks directory underneath our Rails project. To apply Chef
changes, we installed the ‘engineyard’ gem and us ‘ey recipes upload’ and
‘ey recipes apply’ from within our Rails project.

Upside, everything you need to know about the project is local to the project.

.
├── Gemfile
├── Gemfile.lock
├── README.md
├── Rakefile
├── app
├── cookbooks
│   ├── main
│   │   ├── attributes
│   │   │   └── recipe.rb
│   │   ├── definitions
│   │   │   └── ey_cloud_report.rb
│   │   ├── libraries
│   │   │   ├── ruby_block.rb
│   │   │   └── run_for_app.rb
│   │   └── recipes
│   │       └── default.rb
│   ├── redis
│   │   ├── README.rdoc
│   │   ├── recipes
│   │   │   └── default.rb
│   │   └── templates
│   │       └── default
│   │           ├── redis.conf.erb
│   │           └── redis.monitrc.erb
│   └── sunspot
│       ├── recipes
│       │   └── default.rb
│       └── templates
│           └── default
│               ├── solr.erb
│               └── solr.monitrc.erb