Why Twitter Should Really Reconsider Its OAuth Implementation

Posted on April 12, 2011 by Omri

I’ve been working on a new project these past few days that requires user authentication. Those who know me know I love convergence, that is, the more you can condense the tools you need while still keeping the experience the same, the better. That is why I love Adium (though I wish it also did Skype chat); that is why I love my iPhone (Jailbroken because that just adds even more to the convergence); and that is why I love websites that don’t make me register a new account when they do need me to register.

Any good emerging website needs to understand that there are established players: Google, Facebook, and Twitter are examples of services that people may already be registered for. If you can leverage their APIs to cut down on the amount of work a new user needs to do to interact with your service, the user is more likely to actually use it. For instance, if a shopping site lets me check out with either Amazon, Paypal, or Google Checkout WITHOUT making me register for an account, they are more likely to see me there again.

This project that I am working does require a user to make an account; however, this process is mostly transparent to the user. For instance, using Facebook Connect, a user can create an account by clicking the Facebook logo, logging in to Facebook if they don’t already have a Facebook session, and authorizing the application. These 2 or 3 clicks happen so fast that the user may not even realize that when they are redirected back to the site from Facebook, the site is already welcoming them as a registered user. This works great with Facebook, but this post is about Twitter. What does Twitter do (or rather what does it not do) that makes this impossible.

Twitter does not give API access to the user’s Email address. This is a problem as the email address is the only unique field that can distinguish a user in this application. Sure, we can use a username; however, what’s to say that this is consistent among sites? Additionally, what stops someone from choosing someone else’s username from one site to the other. Email addresses usually require confirmation to ensure that you actually own it. You cannot own a username.

So, because Twitter does not let me query a user’s Email address even after they agree to let me use their account for authentication, I have to ask the user to put in their Email address. This detracts from the user experience and makes the registration error prone. The easy fix: give users the ability to expose their email to external applications. One checkbox that can make app development incredibly easy.

TL;DR: Twitter needs to enable Email access through its API.

PS, I’ll be elaborating on my quest for finding a great Rails authentication/authorization system as well as whether or not Rails “magic” is actually a good thing in another post.

Posted in Development, Work | Leave a comment

In The News

Posted on October 19, 2010 by Omri

Qube Lab was recently featured in CBC Magazine

Posted in Work | Leave a comment

Auto_Complete Goodness

Posted on August 12, 2010 by Omri

Zolio has been consuming a large part of my life this summer and I’m happy to say that it’s ready for testing. A few accounts are being generated and sent out to testers today who will hopefully find ways of breaking the site so I can fix it.

The last feature that needed to be added is a way to create classes, assign teachers and students to those classes, create assignments, and have students post files to those assignments.

While this seems to be like quite an undertaking, Rails makes it really easy to do. What was interesting; however, was how the student goes about attaching files:

A student is enrolled in a class. A school has many classes. Classes have many users. This sort of logic grows out of control very quickly. Specifically for the file upload, a user has to specify which class he is attaching his file to; however, he is only allowed to attach files to classes within his school that he is enrolled in.

Because I love autocomplete so much, and because Rails makes it so easy to implement, I chose to use it for helping the user select what class to attach his file to. I could have used a drop down, but they seem so inelegant these days.

Autocomplete works by querying a specific table for a column. As text is typed in the box, javascript is used to keep making calls to the database to narrow down the list. I quickly realized I may run into a problem as we actually need to query two tables.

In one table, we have a list of classes. This list contains the name of the class as well as the school it is associated with. In another table, we have a list of user IDs and the class IDs they are associated with. These class IDs relate to the IDs of the classes in the class table (the one with the name and school). What we needed to do is somehow retrieve a list of the classes only the student is associated with, but retrieve it as a name, not the ID of the class. Pat Shaughnessy’s Auto_complete to the rescue:

In my controller, I have the familiar action for auto_complete:

	auto_complete_for :subject, :name do |list, params|
		list.by_user(params[:uid])
		end

Notice, it’s list.by_user which is a new named scope. Now, in my model I have

	named_scope :by_user, lambda{|user_id|{:include=>:users,:conditions=>["subjects_users.user_id=?", user_id]}}

This runs a join on the tables and finds us the classes (by name) associated with the user through the class ID pivot.

Really fun stuff

Posted in Development, Work | Leave a comment

SQL Woes

Posted on August 3, 2010 by Omri

I have been working on a Rails application for a demonstration at Case. The application is a pretty standard CRM system whose use is to allow faculty on campus to find one another when they need specific things done that are out of their expertise. For instance, a medical student may have a business idea where he may need a rapid prototyping machine with a specific process. He can log onto the system and be connected with any faculty member who has listed this ability.

Apart from being secured behind Case’s Single Sign On as well as the possibility of integrating the Case LDAP Phone Book, the app has few “Wow” technologies. It includes auto-complete on almost all text entry fields so that as a faculty member starts looking for a “Rapid Prototyper”, the minute they type the first R, any machine that includes an R will show up. As they continue typing, the list will be weened out.

What is not so notable but took an incredibly amount of work is one of the requirements:
For example, if a user comes to the system in need of a faculty member with specific expertise, they should be presented with every single expertise present in the system. There are checkboxes next to each one and the user can be as broad or as narrow with their criteria as possible. If the user doesn’t check any boxes, every faculty member (or equipment) is returned. If they check enough boxes so that no member matches the criteria, none are returned.

Here is where it gets interesting.

We have a users table which has all the personal information. We have an equipment table which contains all the equipment. Lastly, we have a process table which contains a list of process names.

There is also a table in the database that links all of these up. This table has a row for each process that is associated with a user and/or a machine. So for instance, if, in my process table, I have a process named “cooking” and it’s table id is 3, and in my user table, I am user 4, there would be a row in this pivot table that would say user_id 4, process_id 3.

The important thing to understand is that one user may be associated with multiple processes, so for instance, we can have multiple rows like this:

user_id process_id
4 3
4 5
3 2
4 2

When the page is loaded, the process database is queried and a list of processes as well as checkboxes is created on the page. The user will then select the processes they are interested in. When they click submit, the magic happens.

Each checkbox value is actually the number of the process_id. Therefore, when the user clicks submit, the application has a list of these IDs that the user is searching for.

A SQL query for getting a user with an ID would look something like this:

SELECT * FROM user_processes WHERE process_id = 3

The question is, how do we get more specific in our query. Let’s say we wanted any user that could cook as well as “chop” (id 5). Instinctively, we would come up with this query:

SELECT * FROM user_processes WHERE (process_id = 3 AND process_id = 5)

However, it turns out that this simple idea turned into a week long headache for me. After trying every possible google search, I finally stumbled upon this question posted on Stack Overflow and came up with what may be the most complex SQL query I have ever seen (though, probably not complex for SQL gurus):

					SELECT  *
					FROM    (
					        SELECT  DISTINCT user_id
					        FROM    user_processes
					        ) mo
					WHERE   NOT EXISTS
					        (
					        SELECT  NULL
					        FROM    ("+@string+

					                ") list
					        WHERE   NOT EXISTS
					                (
					                SELECT  NULL
					                FROM    user_processes mii
					                WHERE   mii.user_id = mo.user_id
					                        AND mii.process_list_id = list.process_list_id
					                )
					        )")

Where @string is dynamicaly generated by Ruby based on the checkbox parameters:

			if (params[:query].length == 1)
				@string =  "SELECT "+params[:query][0]+" AS process_list_id"
			elsif (params[:query].length > 1)
				@string =  "SELECT "+params[:query][0]+" AS process_list_id"
				1.upto(params[:query].length-1) do |n|
					@string+=(" UNION ALL SELECT "+ params[:query][n].to_s)
				end
			end

This was quite a bit of work, but I’m glad it’s finally done. It was a great learning experience and I have to thank my friend Alex Budkie for putting up with me while I complained to him about how much easier this should have been (and for helping me interpret the Stack Overflow response).

Posted in Development | Leave a comment

The Beauty Of Simplicity

Posted on July 27, 2010 by Omri

They say beauty is only skin deep; while that may true, it’s certainly hard to see the real beauty under the face of applications developed on Ruby on Rails (RoR or just, Rails).

RoR is a, relatively, modern language built on Ruby. Developed by 37Signals, Rails has been adopted to developer some of the most notable applications on the internet (Twitter, Github, and Redmine). Even the Yellow Pages uses Rails. The rise in popularity is of no surprise, Rails is both incredibly powerful, as well as incredibly easy to use; a combination that makes it beautiful.

For instance, take the simple example of a for loop in PHP:

for ($i = 0; $i<10; $i++){
echo $i;
}

This would write "0,1,2,3,4,5,6,7,8,9"

In Ruby, this would be written as

(0..9).each { |i| puts i }

(there are much simpler ways of writing this: http://refactormycode.com/codes/2-ruby-simple-loop)

This is just a simple example of Ruby's ability to minimize frustration. While it may take a little getting used to (especially coming from stricter languages like C++), once you understand the language, it is simple and elegant. It reads like a language, not like code.

The great thing about Rails is that it takes Ruby's philosophy and extends it to the realm of web applications. No longer do developers have to write complicated SQL code (with a notable exception). Speaking of the database, relational tables are handled by models, while database changes are source controlled through migrations. Web routes are standardized so that CRUD applications follow the convention of /controller/action (for example creating a new user is usually /user/new). I could go on and on, but the bottom line is application development time is reduced, while code maintenance is eased.

While I still have a few gripes with Rails I have become a giant advocate of the MVC philosophy as well as the direction Rails is taking. It's incredibly easy to develop as well as deploy applications using mod_rack.

If you're interested, the big application I'm developing and launching is called Zolio. There will be a future post about it and its place in education. I'd suggest heading over to the site and subscribing to be notified when Zolio officially launches.

Posted in Development, Technology, Work | Leave a comment