Fernando Salazar

With this installment’s title I must extend apologies to John Donne, though had he lived today I’m sure the great metaphysical poet would have been concerned with more inevitable eventualities than death … like the inevitable need to go online and once there, to login to something.

Logging in and getting a personalized experience with our apps is a universal expectation, not to mention in lots of cases a logical requirement. Back in the day we’d blithely enter our email address yet again, and use the same ‘ol password, just to register with a site we’ll probably use only 1 time in our lives. Well, those days are gone. Not only are users weary of all these separate logins, I as a developer want to minimize the effort I spend on basic stuff, so I can save it for the specific features of my app. So what I decided to do is use OAuth, the standard that allows sites to cooperate on user-identity. In vastly-condensed summary: OAuth allows different applications to share identity information based on shared keys. When you got to a site and see “Login with Facebook”, and click that, here’s what happens:

• The site formats a link to the identity provide – in this case Facebook – that includes a signature. The signature is a long string of data created by processing some input with a secret key.
• The user’s browser is sent to page hosted by Facebook. Behind the scenes Facebook checks the signature, using its own copy of the secret key. Then it asks you, “App such-and-such wants access t your email address, etc. You good with that?”
• Assuming you click “Yes”, Facebook re-directs back top the original site, including its own signed and encrypted data. because that data was  created, once again,  with the same secret key, the app can read it and find your user-name, along with whatever other things you may have approved.

That’s the theory. Now in practice I want to have such a “Login with Facebook:” button on my site. To do that I do what most developers do: Google “rails facebook oauth login”. As expected the 1st page of results had 3-4 tutorials on how to do just that.

What’s the next step? if I was at work I’d most likely read through the candidate articles, pick the best one, then write out the requirements and steps in a new document, then do that. At home, well, I can only say I have a more carefree attitude. I started following the steps of one tutorial that was based on Omniauth and React-Rails (more on React later) but decided after a hour or so that was too much UX work than I wanted to do just now. So I stopped that path and started a different route using Devise, a Rails-based framework that is a largely pre-made authentication system.

Then the hackery began. I removed the original routes I had added with the 1st version,  then used the Devise utilities to generate new ones. if you’re not familiar with Rails, its ‘generator’ facility is used all the time to create config files, stub files, and much more. For example:

rails generate device:install

will create a complete devise configuration, prompting you for settings along the way. Alas, I couldn’t do that all-in-1 step because of the 1st attempt stuff I had in place, so I set out doing it piecemeal.

In the end it all worked, but the process wasn’t pretty. I did have to spend about an hour trying to resolve an error, where I had only this log text to go on:

F, [6 #8279] FATAL — : [c6e010f3-c1b9-4675-90d6-9bdaeb42c1b5] ArgumentError (wrong number of arguments (given 0, expected 1)):
F, [7 #8279] FATAL — : [c6e010f3-c1b9-4675-90d6-9bdaeb42c1b5] app/models/user.rb:19:in `from_omniauth'[ 

This was one of those that looks specific to the problem – line 19 in file user.rb is messed up, right? – but actually did not explain anything. I tried different things, to no avail. Finally I brute force rescued the exception and printed the “real” stack trace, which was:

F, [5 #8280] ERROR — : [7120f455-99a1-4427-922c-053742c6194d] wrong number of arguments (given 0, expected 1)
F, [6 #8280] ERROR — : [7120f455-99a1-4427-922c-053742c6194d] /app/vendor/bundle/ruby/2.5.0/gems/devise-4.5.0/lib/devise/models/database_authenticatable.rb:166:in `password_digest’/

So the crash wasn’t in my code, it was in the Devise framework. The problem turned out to be this: I created my original user-model to use a Rails option has_secure_password. This requires a database column and model-attribute password_digest. However the Devise framework adds its *own* method named password_digest that takes 1 argument. The fix: remove has_secure_password and the password_digest column.

So there it is. If you’re of a mind you can Try the FB Login Demo here.

My closing thought … software frameworks, like cars, are things that people build and because of that you’d think we know everything about them. Well, we don’t. The picture below captures this thought:

Next time: SM Geeking takes on user-interface. Systems architect that I am, comedy is guaranteed. Don’t miss it!

Been quite some time I posted anything here. Anyway I’ve started work on a personal coding project and it occurred to me might be useful / fun / get-something-out-of-my-yearly-Wordpress-subscription to write about how the project progresses. Finally, there’s the (probably vain) hope that starting a thread about the project will induce me to keep working the project. And hope is a fundamental aspect of programming, as anyone who has ever deployed to production can tell you, so here goes …

What is the project about? 2 things: My wife Kim (String-Or-Nothing) is an expert in textile arts like embroidery and knitting. Way, way back in the day I did a site for her, wiseneedle.com, that was a searchable catalog of yarn reviews. The data for that site is long-since sold, but we’ve often chatted about doing another textiles-related project. The second part comes from me recently taking a seminar at Google Cambridge where Google folks presented their latest cloud services and APIs. The machine-learning stuff got me thinking, and looping back to the textile-arts thing, I thought maybe there’s a fun learning opportunity here. So the overall goal of the project is to use Google Cloud and their APIs to make a site for some textile thing, that also uses machine-learning. I know you all thought that was were this was going from the start, right?

What do you need to start such a thing? past few years I’ve been doing a lot of Ruby on Rails, so that’s going to be my main framework. And I said I wanted to use Google Cloud Platform; you get an  account with $300 credit and access to bags ‘o APIs. However, while tis all well and good to ordain yours tools and your platform, getting the twain to meet is another matter. Google has lots of ways to deploy and run stuff: App Engine, Kubernetes, and Compute Engine; here’s an overview for using these with Rails.

Scanning through the options, I wasn’t super-enthused by any of them. Well, as most coders will tell you, you Google enough you’ll find an answer. the answer I found is called Nanobox. Billed as “PaaS V2” it struck me as not unlike Heroku, a PaaS I was familiar with from my last job. This tutorial, on using Nanobox to deploy a Rails app to Google Cloud I was able to read in about 3 mins. In my experience that means I could probably complete and verify the actual steps in about 3 hours. Anyway what Nanobox does is it layers on Google Compute Engine (an IaaS service similar to AWS EC2) a deployment model that allows you – or , me – to de isolated from details of what VMs, what storage, what load-balancers, etc. are needed for your app. Well, I am all about isolation, so at about 10:30 I started in …

Long story short – it worked! The only hitch was, while I created a role for Nanobox to use that had all needed Compute Engine permissions (it had to create a lot of stuff on my behalf), I hadn’t enabled the Compute Engine API in my account. It in fact took a little digging to determine that was the root cause of stuff not working. Well, after fixing that Nanobox deployed “all the things” as we say and my Hello world app was running.

Next time … the wonders of Facebook plus OmniAuth. Booyah!