#omniauth

Been a while between posts. I’ll have to work on that. Anywho, I’ve been struggling a bit with integrating APIs into my rails projects. There are lots of details to work out. There’s usually at least a little bit of new syntax. The biggest problem I’m hitting right now, though, is that when things go wrong --  and things will go wrong -- I’m not getting helpful error messages. Usually the error message reads “Something went wrong.” Not my favorite three words.

And that’s enough of the complaining for this post.

So here’s a couple helpful hints. 1) for an omniauth tuorial, the best I’ve seen to date is Chris Oliver’s GoRails tutorial here: https://gorails.com/episodes/omniauth-twitter-sign-in

That’s the first one I’ve gotten to actually work when it get’s to the point in the tutorial where the teacher says “And now when we refresh it should just work.” Super helpful, step by step guide to adding Omniauth to a fresh project. He gets into a fair amount of stuff that I had been missing. 

He gets into how and why to use either the `secrets.yml` file or system configuration to store credentials. My take so far is to use `secrets.yml` to hold secrets in development and `heroku config` to hold secrets in production. Security tip: always add `secrets.yml` to `.gitignore`.

Another brilliant thing from Chris Oliver’s tutorial is to raise a test exception when your working on an API to stop and look at where things are in the code, step by step. This is a technique I learned during my AppAcademy days but managed to fall out of the practice of using it while following the Hartl Rails tutorial (which is wonderful and helps you get through it by spoon feeding you all the code).

OmniAuthentication (OAuth) allows you to tap into authentication through another site such as GitHub, Twitter, Facebook, and Google. The OAuth gem allows your app to do this through a series of ‘handshakes’ with the other designated app. 

The benefits of this are that you get to draw upon the user security of these larger, well funded applications. 

But, as with all gems, you are relying on an outside source and can only hope they keep their gem updated and keep up with new threats. It can also become complex if you want to add in multiple kinds of OAuth. 

Since you are given access to much of the user’s profile information from the other site, a more conceptual issue arises. Do you update your user’s profile information each time they update their information on the other site? It can get messy.

The way it works is your application redirects a user to the designated authentication site (lets use Twitter as an example) and sends a token request along with your site’s API key and secret. The key and secret tells Twitter that the request is originating from your site and not some fake. 

Twitter then asks the user if it is okay for your application to access the user’s Twitter information. The user must authenticate with Twitter to accept. When Twitter receives the ‘go ahead’, it then sends a payload filled with a bunch of the user’s data to a callback route you set up for your application through the Twitter developer page for your site. Your middleware (Rack) converts this payload information into a hash that Rails can decipher.

https://naveengopisetty.wordpress.com/2014/09/15/linkedin-oauth-2-0-issue-invalid-redirect_uri-this-value-must-match-a-url-registered-with-the-api-key/

https://www.drupal.org/node/2357091

i’ve been waiting a long time to finally implement this. i’m really excited because of course our marketing strategy is inextricably tied to social media, and to that end, authentication is the heart, the root of that.

it’s somewhat ironic that an authentication system is the heart of your marketing, but there it is.  after 3 years now of web development, i now believe that marketing should not only be a priority, but in fact should be the centerpiece of your web app.

your product is almost secondary to your marketing.  your product must be self-marketing.  the primary directive of your app should be to market itself.  i view it like some religions, which have at their heart a mission.  the message is the mission, the mission is the message.  it’s very mcluhan.

you should start with your marketing strategy first, and then build the features.  you should spend more than 50% of your development time on the marketing functionality of your app.  in a sense, your app must be a marketing machine that happens to deliver unique features to your audience.

http://sourcey.com/rails-4-omniauth-using-devise-with-twitter-facebook-and-linkedin/

Testing Omniauth with Minitest

I would like test Omniauth-facebook with MiniTest. This is my code to test.

app.rb

Mongoid.load!("mongoid.yml", :development) on get do on 'auth/facebook/callback' do on param(:code) do |code| email = req.env['omniauth.auth']['info']['email'] user = User.where(email: email) unless user.nil? user = user.first else user = User.new({email: email}) user.save end end on 'auth/failure' do puts…