Wednesday, December 31, 2014

UPDATE: HOWTO Mailchimp's OAuth2

I have been working to integrate the Mailchimp OAuth implementation into an application that uses mailchimp mailing lists to drive call campaigns. My users login into my site using mailchimp, so you can see its going to be a very strong integration.
I have found a few problems with the implementation. This is about my 10th OAuth implementation so I am pretty familiar with all the little implementation differences. Here are a few crits, meant to be constructive. 
Here are some details. I am using the Mailchimp python API on bitbucket and the Bananas_OAuth implementation.

Mailchimp Python API -
Banana Py Oauth -

  1. Its seems as though the calls from don't return enough information to reliably create a user in the authenticating system and that the API does not have a method to get data on the OAuth user that the access token was generated for. This creates a problem when attempting to create a user for the first time. When user authenticates the following information should be in the response: email address, unique unchangeable id, and mail chimp username. Right now I have to use the "account_name" which can be changed. Can you see where this might be an issue? I also have to generate a fake email and force the user to verify the email when I could just use the one you verified already. This can be dealt with using the account-details method in the helper api.
  2. The OAuth implementation does not implement scope.
  3. The OAuth implementation does not use best practices for refresh tokens.
  4. The OAuth implementation is difficult to implement a flow for, I have implemented about 10 of these and I couldnt figure it out from your docs. If Bananas wast there I would have ended up spending an insane of of time.
  5. Making the API docs say that the calls use the API key is confusing I had to read deep to see that you could use an access token to make calls.
  6. Why doesn't it have a OAuth implementation in the API, c'mom just add Bananas_OAuth and do a little more architectural work to unify the concepts.

UPDATE: Cole from Mailchimp API got back to me in a day and gave me a solution for #1, I added this to the Gist as well. Looks like it works.

I have a Gist that shows some of the backflips I am having to do, its too bad too because with some very small changes the OAuth2 implementation and API would be pretty darn good. Check out what I am doing:
I am also giving you a reference to an OAuth implementation that is solid and easy to implement:

Friday, November 21, 2014

Now you tell me.

Play 2.0 Support is Now Part of the Scala Plugin

The key change we’d like to highlight is that the Scala and Play 2.0 plugins have merged together, so with IntelliJ IDEA 14 you don’t need to install them separately because Play 2.0 support is now a part of the Scala plugin. You still need to run IntelliJ IDEA Ultimate to enable Play 2.0 support though.

Saturday, November 01, 2014

Why Google's Oauth2 implementation is poor

When comparing oauth2 providers I find that Google, while being the most compliant has the absolute worst working examples of their code. Everytime I see example code from google I get the mental image picture of a 24 year old developer who claims "its works!" while not even considering how someone who has never used the technology they are proposing may interpret their completely uncommented code base.

Really? So I attempted to get this framework working in my app for hours. It requires that you use the google model objects and the xsrfutil libs to work (I guess I never got it to).


This FLOW framework obscures the oauth2 process from the developer, so you are completely dependent on the code base being simple to understand to get the implementation working. Secondly creating the oauth2 app client credentials are buried deep in google's "API Dashboard". It was the longest amount of time I have ever spent on an oauth2 implementation. I have done many of these and this one is very difficult to work with.

Compare this to oauth2 providers that actually give you the curl approaches directly, and allow you to compare it to their API. Their oauth2 implementation is not hidden, and you can easily figure out what needs to be done.

Pretty good outh2 implementation, well documented, easy to use API. Poor user object returned on successful auth in some cases.

Its good. Period.

Good implementation and documentation. The python examples were a little off but a python dev can figure it our. Their support responds to problems. Worthy.

Here are my recommendations to oauth providers:
  • Make the entire three legged process easy to natively implement via curl commands.
  • Build auth apis that are simple extensions of that flow 
  • Make sure that the client api can access enough user information to create a user record on the target app without asking for more information. 
  • Make it easy for developer to create client app secrets and manage multiple environments.

Saturday, July 05, 2014

Apache 2 SSL Cert and Config


I am installing a SSL cert for Apache2 and I thought I would document it. I have done it so many times now and kinda feel like its about time to have a place to go to to get the details quickly. I am using a domain level cert because its cheap and will provide encryption without having to verify my "business" (there isnt one yet). The cert I am using for this is Comodo's positivessl cert from that costs 9.99

Apache2 + mod_ssl



Saturday, April 26, 2014

Actual Coinbase Client HTTP (Get & Post)

I like coinbase, seems like a pretty robust API, but sadly there are documentation bugs and they arent so hot at replying to support issues. After some thinking I figured out why the API calls were thinking they were not JSON.

Thursday, April 03, 2014