Diaspora API Dev Progress Report 1

I’m only a few hours into getting fully going on the Diaspora API development project.  I had been pre-flying that whole experience earlier last week by studying the existing code base, familiarizing myself with the discussion threads et cetera.  Over the last couple of days I’ve been trying to focus more on moving the ball forward as well.  Before really doing that though there is still a little ground work to do.

As I wrote in my first post on this topic, I needed to setup a test production server and complete the assimilation of all of the code and discussions.  I’ve completed those things mostly pretty quickly.  I created a new VM with enough horsepower to run a good Diaspora based on my dev experience.  That’s a machine with 8GB RAM and 4 CPUs.  For the first time I followed the “production” rather than “development” setup instructions.  It wasn’t long before I had my server ready to go but only with HTTP connections.  Oh well, I’ll get back to the HTTPS thing later, I thought.  It turns out that this test server has been great for me to test some other PRs that I’ve been working on in a way where I’m sure that I’m not seeing an artifact of being in the dev machine, but that can be another post. With the machine ready to go it was time to start getting my hands dirty with the code.

First order of business was to rebase the API branch to the head of the development branch.  While Frank has been working throughout the summer on the code the two branches hadn’t been rebased in more months than that.  This wasn’t a huge thing at all, in fact I didn’t have to make a single change.  All the unit tests passed before and after the merge seamlessly and there were no merge conflicts.  This allowed me to test my collaborator capabilities in Frank’s fork and work with the PR system on his fork as well.  With that done I was ready to start real testing.

I explored the unit tests, in both regular and debug mode, for some existing endpoints.  They all seem to be working as I would expect for what they are.  However what is it like to try to use the endpoint from an actual application.  This is where there’s a combination of short comings in my experience with OpenID (the authentication layer), Rails, and (perhaps) some documentation.  I’m trying to use both cURL and some browser plugins.  Reading the Diaspora API spec and the links back to OpenID I tried to make my way around getting a successful authentication request.  Slowly but surely, playing around with QPs, Request Bodies, and the like I finally got an application registration working and it was time to try to make an authentication request.  Sadly, at this point I hit a roadblock.

I believe, although I may be wrong, that I really need to be running the server in HTTPS mode.  When I run it in HTTP mode the OpenID library responds with a “Can’t verify CSRF token authenticity” error and bombs out to a redirect.  When I throw the server configuration to HTTPS mode however the browser comes back with a “SSL_ERROR_RX_RECORD_TOO_LONG” error.  So I’m sort of stuck between a rock and a hard place.  I figured this would be like installing a certificate on Tomcat where I can find any number of Stack Overflow articles to say nothing for blog posts, server documentation, etc.  While there is documentation on enabling SSL or not the actual installation of certs has been illusive.  I have a list of articles that show doing this for “puma” and “thin” servers but we aren’t running either of those in Diaspora as far as I can tell.   The Diaspora installation documentation, wiki, and Discourse board haven’t shown me a solution either.  With a post to the discussion boards for help I then thought to myself that I probably need to have a better understanding of what the OpenID library is doing and its configuration.

I’ve found some sample Rails apps that use the OpenID gem that we are.  While doing some more exploring and waiting to hear back from other Diaspora admins and developers I’m going to start exploring that to really get used to how the server side works and what the client side will look like both in browser-based applications and maybe in library versions as well.  I’m approaching that as MVP type understanding however to just save me some debug/development iteration time later not to be an expert on all these topics across a huge breadth of languages.

Leave a Reply

Your email address will not be published. Required fields are marked *