codelevy

OpenID Integration - Pros and Cons

Posted by Lance Ivy Tue, 02 Oct 2007 11:36:00 GMT

OpenID integration has certainly become more popular, and I’ve started building a generic Rails application shell built on 100% OpenID reliance. So I’ve thought about it a bit, and I’d like to take a look at some of the pros and cons surrounding OpenID integration.

Benefits of OpenID

no passwords

This is not trivial! Not having passwords means not having to worry about password encryption in your database, which lets you toss a couple fields out of your users table right away (password, password_salt). It also simplifies your form – no more please-enter-your-password-and-could-you-confirm-that-please? Furthermore, you don’t have to worry about resetting passwords and sending emails and, well, you get the picture.

trusted user data

With OpenID you can get trusted user data from the OpenID server. This’ll simplify your signup form quite a bit! All you need to do is collect an identity url, and use that to lookup the user’s name and email, etc.

And this is trusted data, so you don’t need to verify the email address (“please type it a second time…”). You don’t even need to activate the user! What’s the point? You can already trust that the email address is valid, so what good is a please-check-your-email-and-click-the-activation-link routine going to do you?

Drawbacks of OpenID

actually getting the data you asked for

The OpenID servers I’ve tried (notably MyOpenID) will listen when you say certain fields are required (name & email), and will tell the user when those fields are missing, but will still let the user bounce back to your application. Why? Now your application has to validate the data, complain, and ask them to try again? Why doesn’t the OpenID server do that for you?

signing up for two services at once

What happens if the user doesn’t already have an OpenID? You’ve got to convince them they want it, and motivate them to go sign up for a second service. Psychologically that’s a big deal. You’re trying to get as many people to sign up for your application as possible, yeah? You’re worried about conversion? You’re familiar with the idea that many people have some baseline of resistance to signing up for new things? Well how much harder is it going to be getting them to sign up for two new things at once? How much energy will the user have left for your application once they’ve figured out this whole “OpenID thing”?

routing signups through OpenID server

This is the biggest con for me, and I hope to see a library that simplifies this soon. To really use OpenID you have to route not only logins but signups through the OpenID server. The login routine is pretty simple now thanks to the open_id_authentication plugin, but signups are still a pain. Yes, your signup form is incredibly simple (“What’s your OpenID, and do you accept our terms and conditions?”), but now your controller has to postpone validation (you don’t have the name/email yet), bounce the user against their OpenID server, then (hopefully) validate and finish the process. This is certainly made more complicated in a RESTful application, because the OpenID server is going to bounce the user back via GET when you really want POST.

Mixing OpenID and Traditional Auth

Ok, so some people get scared by the cons. Those’re some big and scary unknowns, right? But they still like the idea of OpenID, so they implement OpenID alongside their traditional system. Hah, ok, go ahead, but now the application still has to support passwords (even if they’re not always needed) and activation and user data verification, and it has to branch the authentication logic to support the worst of both worlds. So why do it? What possible gain is there running both side by side? The way I see it, running both is just a way of saying “I wish upon a star that OpenID had better adoption and usability”. Supporting OpenID as an alternative doesn’t really push adoption, and it doesn’t simplify the application at all (just the opposite).

Conclusion

The big pros and cons tend to hinge around the signup process. There are very tangible programmatic benefits to using OpenID, but they’re balanced by a worry that we’re leaving behind one conversion process (a comfortable and familiar but still clunky signup process involving typing passwords and emails twice and checking your inbox for an activation code) for an unknown (slimmer signup forms balanced by reliance on a third-party server’s user experience).

But the OpenID servers out there seem to think that they’ll become popular if they court the users. They seem blind to the needs of the application itself, and what they really need to do is make all parties happy.

In the end, we need the early adopters to risk it all and get the momentum going. We need to hear success stories, and we need to polish the rough edges. But what we really need is an OpenID server that won’t make web interface designers lament the user experience of the signup process.

Tags openid

Blog Switcheroo

Posted by Lance Ivy Thu, 20 Sep 2007 12:39:00 GMT

I’m just about done switching my blog from codelevy.wordpress.com to this Typo install. It really is nice to work with a Ruby on Rails blog—creating my own theme and tweaking a plugin or two was all very comforting and familiar. Anyhoo, I’m sure there’re still a few rough edges, so mind your step. When I’ve polished this theme up a bit more and someone reminds (read: bugs) me I’ll package and release it into the wild.

Tags site | 1 comment

Announcing RecordSelect 0.9

Posted by Lance Ivy Thu, 16 Aug 2007 20:04:00 GMT

I finally stopped being lazy and announced RecordSelect, a Rails plugin I developed to provide better usability and performance than a dropdown for picking a record from a list. This forced me to clean up the docs and prettify the demo. Here’s the announcement:

Have you ever needed to ask the user to pick one of a list of records? Ever struggled with the usability and performance of generating a humongous dropdown list?

RecordSelect is my answer. It provides a paginated, searchable, and RESTful way to browse a list of records and select the right one. It even allows keyboard navigation, because I thought that sounded pretty cool.

Want to see more? Check out the demo app from SVN.

Feedback is appreciated! Even if it’s a friendly “yo, something else already does this … better.”

Posted in Ruby on Rails, Open Source, Releases | Tags recordselect | no comments

Improving Single Table Inheritance in Rails

Posted by Lance Ivy Thu, 26 Jul 2007 19:11:00 GMT

I started digging into STI recently and noticed people wondering how to restrict which attributes apply to which subclass. The general attitude seems to be that you just don’t – STI is meant for differences in behavior. Well I don’t completely buy, since I definitely have an is_a? situation here just crying out for model subclassing. And I also believe in locking down the data model as much as possible, and I want self-documenting code that tells people which attributes are intended for which subclass. So I scoped out the situation and came up with the following simple ActiveRecord::Base patch:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class ActiveRecord::Base
  class << self
    def set_unused_columns(*columns)
      @unused_columns = columns.collect {|c| c.to_sym}
    end
    def unused_columns
      @unused_columns || []
    end

    def columns_with_unused_columns
      unless @columns
        @columns = columns_without_unused_columns.reject {|c| unused_columns.include? c.name.to_sym}
      end
      @columns
    end
    alias_method_chain :columns, :unused_columns
  end
end

I’m sure this could be improved, and anyone is welcome to do so. But anyhow, make sure to require the file from your environment.rb, then use it like this:

class ParentClass < ActiveRecord::Base
end

class MySubClass < ParentClass
  set_unused_columns :some_column, :some_other_column
end

Posted in Ruby on Rails, Open Source | Tags STI | no comments

ActsAsProxy

Posted by Lance Ivy Thu, 05 Jul 2007 22:50:00 GMT

At RailsConf07 someone asked me how to simplify forms in ActiveScaffold. What they wanted was to blend attributes from an associated model in with the main model. The premise was that the user doesn’t need to know about the separate models, so why differentiate them on the form? Well we talked and came up with a solution where you proxy methods from one model to another, then add those methods to ActiveScaffold as virtual attributes.

People are still asking about this. I figure it’s time to abstract the behavior, right? Introducing ActsAsProxy, a very simple plugin that lets you do something like:

1
2
3
4
5
6
7
8
9
10
11

class User < ActiveRecord::Base
  has_one :address
  proxies :address, :city, :state, :zip
end

u = User.new
u.address_city = 'Schenectady'
u.address_state = 'New York'
u.address_zip = 12345

assert_equal u.address_city, u.address.city

Posted in Ruby on Rails, Open Source, Releases | Tags ActsAsProxy | 2 comments

custom search and replace (csed)

Posted by Lance Ivy Wed, 04 Jul 2007 12:29:00 GMT

So you’re working on a large codebase and need to change something. But it’s all over the place. Why hunt it down when you can do an easy search-and-replace right from the shell? I wrote this shell script back in my PHP days when I had to move some database tables around. It’s not the prettiest (it is written in bash), but it’s functional and gets the job done.

To install, place this script in your $PATH (I like to put stuff like this in ~/bin/) and you’re good to go. The csed script operates recursively from your current directory.

Script is available after the jump.

Note: there’s a bug I haven’t bothered to fix related to the result set size. It’s really benign, don’t worry.

Posted in Open Source | Tags csed, searchandreplace | no comments