casperfabricius.com

I would never recommend a client to have login and registration in “pop-up” dialogs instead of plain pages, but sometimes clients choose to kindly ignore my well meant advise and ask me implement such things anyway. I’ve just finished version 1 of an upcoming web application implemented with Rails 3 and – of course – Devise for authentication, and this app just happens to have sign in and sign up taking place in dialogs (or overlays) and submitted to the server via AJAX. I expected this use of Devise to be pretty common use case, but the implementation turned out be pretty tricky.

Devise is a pretty amazing authentication system. It’s modular, flexible, highly configurable and lots of extensions have already been built. It does, however, make the assumption that you want to redirect the user to a new page after he has been authenticated. When sign in takes place in a dialog that is submitted via AJAX, a redirect to the frontpage or somewhere else is not of much use. In this case we need to respond with a javascript snippet that either makes a client-side redirect, or – better yet – simply closes the sign in dialog and updates any elements on the page that depends on sign in status.

For this particular web application, the scenario was even more complicated. When an unauthenticated user wanted to comment on something, the sign in box would have to pop up in a dialog. If the user wasn’t registered with the site, he could click a link to get the sign up shown – still in the same dialog. Whether the user registered or just signed in, the dialog should finally display the form for writing a new comment. All this would have to take place through AJAX without the actual page location ever changing, and here is how I implemented it.

Read the rest of this entry »

Key points

• The endpoint for federated OpenID login for Google Apps is https://www.google.com/accounts/o8/site-xrds?hd=[myappsdomain.com].
• For the Ruby OpenID gem to play nicely with Google Apps, Google’s own extension gem for this purpose must be loaded and required with require 'gapps_openid'.

The story

I’ve been working on a client project consolidating most of their various internal databases, spreadsheets and ad-hoc lists into a coherent and centralized web application – employee lists, inventory and so on. Early on the client said to me: “Since we are using Google Apps for email, calendar, document sharing and pretty anything else it can do, it would be really nice if we could simply login to the application you are building using our Google Apps logins.” I said: “Sure, how hard can it be?” It was a fair request that made a lot of sense. After all, everybody hates another login to remember, so wouldn’t it be nice if the employees was simply – “as by magic” – instantly signed in to this new application?

I knew a lot of people was doing sign in with ordinary Google accounts. I had also implemented it myself for darebusters, although the easy way using the very nice RPX solution from JanRain. I could see that I could integrate with Google Apps using both OpenID and OAuth. I had some vague ideas about OAuth being “newer” and “cooler” than OpenID, and also I was using Warden and Devise for authentication, for which a nice OAuth extension existed, so I set out to authenticate against Google Apps with OAuth.

Read the rest of this entry »

I have darebusters.com running on Heroku and I have a worker running Delayed Job (DJ) activated. This allows me to handle heavy tasks such as video processing and payment transactions asynchronously, so the dynos can get right back to serving requests.

I also use DJ to send out emails, and a typical asynchronous call sending a message from one user to another – scheduling a delayed job – used to look like this:

UserMailer.send_later(
  :deliver_message,
   @recipient,
  current_user,
  params[:message]
)

Since darebusters.com is an internationalized website currently offering users the choice between English and German, this has proved a slight challenge, however. We have the usual internationalization (i18n) bells and whistles: Flags to select the language, and remembering the user’s language selection in session, cookie and in the users database table. By default, a delayed job will simply run with the default locale of the site. It has no way of accessing the context it was invoked in, so it cannot set the locale from session or cookie. The job only knows what it can work it from the arguments it was created with.

Read the rest of this entry »