Code Iteratively » howto

Upgrading your Authlogic Gem for Rails3

Christopher Gooley — Fri, 03 Sep 2010 08:45:17 +0000

If you’re using Authlogic in Rails3 (or if you’re upgrading your existing app from 2.3.8 to Rails3) you really need to be using the rails3 branch of the Authlogic gem. If you’re using Bundler, this is super-easy because you just need to update your Gemfile.

In your Gemfile, update the authlogic line to be:

gem 'authlogic', :git => 'git://github.com/odorcicd/authlogic.git', :branch => 'rails3'

Now you should run $ bundle install to grab the new gem. Then, there are just a few more deprecated things in Rails3 that you’ll need to change in your upgraded app. I’ll try to enumerate here from memory, so please forgive me if I forget something.

First, you need to update your ApplicationController because #requesturi is outdated. Replace it with #fullpath:

def store_location
  session[:return_to] = request.fullpath
end

Second, you need to drop the filter_parameter_logging setting from your ApplicationController because it’s now handled in the new application.rb file. Just remember to add the :password_confirmation field to the default array like so:

# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password, :password_confirmation]

Third, if your migration script (or the steps you followed manually) didn’t get rid of the /config/initializers/cookie_verification_secret.rb file, delete it now. Cookie secrets are now handled in the /config/initializers/secret_token.rb file.

Fourth, the f.error_message construct isn’t available anymore in core rails, so you should take this opportunity to create your own better more customizable error messages. If you really really want to keep using f.error_message you can install the dynamic_form plugin, but don’t do that. Railscast.com did a very nice explanation of how to create your own shared _error_messages.html.erb view (along with some other validation-related stuff.)

Finally, you need to make sure your generated pages include the csrf_meta_tag. Check out my previous post if you’re getting an InvalidAuthenticityToken error when you hit the Logout link.

That should be all you need to do to have Authlogic working in Rails3 without deprecated warnings.

InvalidAuthenticityToken on Logout when using Authlogic

Christopher Gooley — Fri, 03 Sep 2010 08:07:46 +0000

This one took me a while to debug. When upgrading my existing application to Rails 3 almost everything was working fine except whenever I would click the Logout link I would get an error because Rails couldn’t verify that the UserSessionsController#destroy request was valid from my app.

This is the error message shown:
ActionController::InvalidAuthenticityToken in User sessionsController#destroy

actionpack (3.0.0) lib/action_controller/metal/ request_forgery_protection.rb:96:in `verify_authenticity_token'

And the solution is simple, you just need to add the new csrf_meta_tag helper to your generated page (probably in the /views/layouts/application.html.erb file).

...

  
  Some Title
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>

...

Line 7 is the one you care about and need to have in your html.erb file.

This helper includes the appropriate meta tags which make the authenticity_token available to the handleMethod javascript function. In Rails3, links generated with the link_to helper which use a :method other than GET get passed through that handleMethod function in rails.js. That function creates a temporary form, sets some parameters and submits it. And if you’re using protect_from_forgery (you should be) all non-GET requests are checked to prevent Cross Site Request Forgery (CSRF). So, if those meta tags don’t exist on your page, the handleMethod function doesn’t know what your authenticity_token is, and the request will be rejected with the error above.

Line 5 below is an example of my main nav logout link that was causing the problem when clicked. No change was required to this code after doing the above fix.

<% if !current_user %>
  <%= link_to "Log In", new_user_session_path %> |
  <%= link_to "Register", new_account_path %> |
<% else %>
  <%= link_to "Logout", user_session_path, :method => :delete %> |
<% end %>

This isn’t specific to Authlogic’s logout click – any time you are using link_to now in Rails3 with non-GET methods, it uses unobtrusive javascript. And if you’re missing the csrf_meta_tag helper, any unobtrusive javascript posts will fail to validate.

HOWTO: Export IIS7 Configuration to Another Webserver

Christopher Gooley — Wed, 10 Jun 2009 21:15:15 +0000

IIS7 has this great new feature called Shared Configuration. Except that it has a tendency to do horrible things which usually result in all the websites and application pools being removed from your server and your production website starting to serve 503 Service Unavailable errors.

For an innexplicable reason, Microsoft decided to kill the Export function from IIS7 in favor of this new feature. But for those of us who don’t trust technology, we like to do things manually and to get a repeatable result that doesn’t update automatically when we least expect it. Yes, I am the sort of person who wonders why the default Windows Update on servers is to Install and Reboot Automatically at 2am…

In any case, in a simple 3 step process you too can export and import your Internet Information Server 7 websites and app pools.

I will call the target server TWEB (this is the server where you want a duplicate configuration) and the source server SWEB (this is where the current configuration exists).

First, on TWEB make a backup copy of the files in C:\Windows\System32\inetsrv\config. I just created a subfolder called “bak” and copied them. This is very important. If you forget or skip this step because backups are for sissies, you will be re-installing IIS7 in step 4.

Second, copy the AppliationHost.config from SWEB into the C:\Windows\System32\inetsrv\config folder on TWEB. Also copy any application files like your c:\websites folder or whatever over to TWEB in the appropriate location if you haven’t already.

Third, on TWEB open both the new ApplicationHost.config and the backup ApplicationHost.config from step 1 and locate the node in the backup. Copy that node and replace it into the new config file.

Fourth, if you didn’t backup the existing config file, remove the IIS role and add it back, then start at step 1.

Note: if you have custom accounts under which you’re running app pools (cuz you’re not using LocalSystem, right?) then you just need to go into the IIS Management Console and re-configure the passwords for those accounts. They were encrypted with the other server’s AES keys so they won’t be valid on this server and the pools won’t start.

That’s it. Hope that helps. It should work the same for C# .NET applications (which is what I’m using) or just static websites or whatever. But of course, you shouldn’t trust me. Test it yourself first.

My new good-karma policy is that if I spend more than an hour tracking down a general bug or wacky configuration thing, I promise to blog the solution.