Why you should use reCAPTCHA in public websites?

The problem:

We've developed an API which allows users to search and upload Images.
Any application that wants to query it uses an API key which allows it to perform different actions according to its permissions. 

Recently we started to expose some of the API's abilities in public websites.
For example, see the PicScout Search Tool on www.picscout.com (and press the "Launch Tool" button).
Here’s the issue: Exposing the key to unknown users can make us vulnerable to spam and abuse.

The solution:

In order to overcome this problem we decided to use Google reCaptcha.

Using this tool means that only real people can pass through the system, as opposed to malicious bots.                         

Reaching this solution included client and server side adaptations. On the client side, we added support to the reCaptcha widget. This widget is shown to the users before their first action in the site and afterwards only if their token has expired. On the server side, we added a second layer of authentication. This authentication is enforced only on API keys that are public, meaning those used on public sites. When making a request, the users must send an API key as well as a token supplied to them by Google reCaptcha. The server verifies this token combined with some secret agreed between the server and Google. If this information is successfully verified, the resource is returned to the user. Otherwise, the request fails.

That's about it on how we use  reCAPTCHA at PicScout.

Riddle me this

We recently published some code riddles,

It was really fun writing them and we had a lot of good responses from Software developers who enjoyed solving them.

The solvers of the riddles got a nice T-Shirt:

For those of you who enjoy riddles here they are:

1. Follow the bread crumb trail from here:
   
2. Go to http://riddle.guru 

Enjoy :-)

Managing dependent jobs in Jenkins

The problem

It is well known that Jenkins can handle job dependencies based on maven dependencies.

But, how can we manage dependencies between Jenkins jobs that are based on .Net code?
Of course, we can manage job dependencies manually, marking in each job what are its dependent jobs, this takes a lot of time to maintain and is also error prone.

We looked into some options (there weren't many) and couldn't find anything that quite fitted our needs.
This is because here in Picscout, each of our Jenkins jobs is mapped to a single solution.
It can run MSBuild , or unit tests on each relevant project in the solution.
If, for example, we take NDepend powerful API and try to adjust it to our needs, we can use it to know what assemblies are referenced by our solution's projects.
But what are the solutions that hold those assemblies? and by what order should we build them? this is for left for us to implement.
Surely there must be a better alternative.

The solution

We decided to write something of our own.
We wanted a tool that will integrate well with Jenkins.

While Jenkins can run any type of script or executable, if you run your code within Jenkins itself (using groovy system script) you will be able to use its internal API, to do things like start new jobs, wait for them to complete and analyze their build result quite effortlessly.
This however means you have to write your code on a JVM based language-

That is why we opted to write our tool in Java.

The dependency tool we wrote can map solution and project files in given folders and build a dependency chain for each project and solution.

Given a project, it can tell you what projects (by order) will be affected as a result of a change in this project and same is true for solutions.

Now, all that is left to do is to integrate it with Jenkins and Git.

Git/Jenkins Integration

The process we built is made of a few steps:

1. We use git-hooks to identify changed folders, we than find what solutions are in those folders.

2. We send the list of changed solutions to a special job we wrote in Jenkins.

3. The job runs a small Groovy system script , this script finds the dependent jobs using the dependency tool, runs them and and decides if the git commit can be accepted to our master branch (if all the jobs passed).

finally, the dependency tool can also be integrated with Jenkins dependency grpah view plugin to draw the dependencies :

(we are still working on this one)

Source/Deployment

The dependency tool can be found here along with some example usage projects and groovy scripts.

The tool is also deployed in Maven repo.

Please notice it is licensed under the MIT license.