Git: Living on the Edge isn’t for the Dumb

As you may know I’ve been using git as my primary ftp, version control and way to put my projects online for public access and viewing. However, there is a very important thing when considering using these great technology: .gitignore.

Now, when using oAuth, you need a client identity and a client secret. For me, I don’t want to hard code them because that will make them publicly accessible so I stored them in a json file. I thought I followed ignoring the json by adding


to the .git/info/exclude file, however I did not do it right
as ^(.*)/secret.(.*)$ is different than ^(.*)secret\.(.*)$ and quite possibly is completely incorrect

Now first i uploaded it to github, only to find that the file was still there. This through to a flurry as for the last three commits I had assumed everything was peachy clean (I am still learning everything so I don’t hate myself for it. Luckily I was able to find this tutorial on github.

Not only was I able to remove my secret from the commit, but also able to add to the .gitignore in a simple manner. My fears relaxed and a feeling for relief ensued.

Just to add to the security, I also made a proper .htaccess to hide the file

RewriteEngine On
RewriteRule ^(.*)secret\.(.*)$ /404 [L]


Google API + WordPress: A Problem, an Inconvienience and a Killer

I started off planning on using Google Calanders to store my clockin information. I was doing this for one main reason: Its important that how I store the information is standardized in case I attempt to export my plugin to node.js or another platform. But there is a problem I ran into that I realized may turn very annoying or worse.

Refresh Tokens are not unlimited

this will create an awkward situation once the refresh tokens run out and the website owner is forced to login and authorize again

And as a minor inconvienience

Google Authorization Doesn’t allow Get parameters in the url

Perhaps this is a problem on WordPress side more than googles in the way they setup their admin. Essentially I’m forced to create a plugin url that is independent from the direct flow. Making either the user Leave the admin interface conpletely or doing it through a popup. Then Instead of storing it in WordPress Options, we’d be storing it in a seperated SQL table to avoid loading wp-load.php. These are definitely managable, though not entirely preferable. If I’m using a content management system, I’d rather feel as though I can do everything in a very sexy and clean manner. Rather than go through hoops.

nonetheless I will continue to make the plugin as is simply for experience sake. Though I recognize this is definitely not final version

Update: What Killed using Google API as a web service was the fact that I am forced to use give my webserver an key file. This will not make future installations happy for random people. As a Result, I’m going to drop google calander from the design spec and move onto something else. This isn’t necessarilly Google Calanders Fault, but rather a design philosophy Flaw. I wanted to Use Google Calanders as My database, but I didn’t want to have to make installation a hassle. as a result, I gotta move on.

I’ll go with what is important

  1. Start DateTime
  2. Duration in seconds
  3. Github User
  4. Github Project