Veerasundaravel's Ruby on Rails Weblog

May 13, 2011

Google Recaptcha in Rails

Filed under: Gems, Plugin, Ruby, Ruby On Rails — Tags: , , , , , , , , — Veerasundaravel @ 3:43 pm
The logo of reCAPTCHA

Image via Wikipedia

A CAPTCHA is a program that can tell whether its user is a human or a computer. You’ve probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from “bots,” or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs. reCAPTCHA  is google product and its a better and alternate solution to the existing image captchas. You can read the complete story about Recaptcha using this link.

Lets Kick Start:

In order to use google recaptcha, we need to register our site in google recaptcha site. Refer this link for registerting your application Refer the screenshot below for further assistance.

Once after entering you domain name, you can click on the Create Key button. Which will create the required API keys and redirect you to the next listing page where you can get the API details as below:

ReCaptcha helpers for Rails apps:

So when you are ready with API keys, you can start the reCAPTCHA integration into you Rails application. We have rails Plugin called recaptcha, it is more useful and easier for the integration with Rails.

This plugin adds helpers for the ReCAPTCHA API. In your views you can use the recaptcha_tags method to embed the needed javascript, and you can validate in your controllers with verify_recaptcha.

See the RDOC documentation for more information on usage.

Rails Installation:

reCAPTCHA for Rails can be installed as a gem:

                       config.gem “ambethia-recaptcha”, :lib => “recaptcha/rails”, :source => “”

Or, as a standard rails plugin:

                       script/plugin install git://

Setting up your API Keys:

There are two ways to setup your reCAPTCHA API keys . You can pass in your keys as options at runtime, for example:

                       recaptcha_tags :public_key => ‘6Lc6BAAAAAAAAChqRbQZcn_yyyyyyyyyyyyyyyyy’

and later,

                       verify_recaptcha :private_key => ‘6Lc6BAAAAAAAAKN3DRm6VA_xxxxxxxxxxxxxxxxx’

Or, preferably, you can keep your keys out of your code base by exporting the environment variables mentioned earlier. You might do this in the .profile/rc, or equivalent for the user running your application:

                       export RECAPTCHA_PUBLIC_KEY  = ‘6Lc6BAAAAAAAAChqRbQZcn_yyyyyyyyyyyyyyyyy’ export RECAPTCHA_PRIVATE_KEY = ‘6Lc6BAAAAAAAAKN3DRm6VA_xxxxxxxxxxxxxxxxx’

If that‘s not your thing, and dropping things into config/environment.rb is, you can just do:

                       ENV[‘RECAPTCHA_PUBLIC_KEY’]  = ‘6Lc6BAAAAAAAAChqRbQZcn_yyyyyyyyyyyyyyyyy’ ENV[‘RECAPTCHA_PRIVATE_KEY’] = ‘6Lc6BAAAAAAAAKN3DRm6VA_xxxxxxxxxxxxxxxxx’

Displaying reCAPTCHA form:

Recaptcha gem offers you a helper method called recaptcha_tags which can display the reCaptcha form for you in your view files as follows:

Some of the options available with recaptcha_tags:

:ssl ==>    Uses secure http for captcha widget (default false)
:noscript ==>    Include <noscript> content (default true)
:display ==> Takes a hash containing the theme and tabindex options per the API. (default nil)
:ajax ==>    Render the dynamic AJAX captcha per the API. (default false)
:public_key ==> Your public API key, takes precedence over the ENV variable (default nil)
:error ==>    Override the error code returned from the reCAPTCHA API (default nil)

You can also override the html attributes for the sizes of the generated textarea and iframe elements, if CSS isn‘t your thing. Inspect the source of recaptcha_tags to see these options.

Verifying ReCaptcha:

Using verify_recaptcha method you can easily find out the correct input from user for the displayed captcha.

This method returns true or false after processing the parameters from the reCAPTCHA widget. Why isn‘t this a model validation? Because that violates MVC. Use can use it like this, or how ever you like. Passing in the ActiveRecord object is optional, if you do—and the captcha fails to verify—an error will be added to the object for you to use.

Some of the options available:

:model ==>    Model to set errors
:message ==> Custom error message
:private_key ==> Your private API key, takes precedence over the ENV variable (default nil).
:timeout ==> The number of seconds to wait for reCAPTCHA servers before give up. (default +3+)

respond_to do |format|
    if verify_recaptcha(:model => @post, :message => ‘Oh! It’s error with reCAPTCHA!’) &&
        # …
        # …

October 4, 2010

Jekyll – Ruby gem for static site generation

Filed under: Gems — Tags: , , , , — Veerasundaravel @ 12:09 pm

Jekyll is a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server. This is also the engine behind GitHub Pages, which you can use to host your project’s page or blog right here from GitHub.


Creating a Jekyll site usually involves the following, once jekyll is installed.

  1. Set up the basic structure of the site
  2. Create some posts, or import them from your previous platform
  3. Run your site locally to see how it looks
  4. Deploy your site

Basic Structure

Jekyll at its core is a text transformation engine. The concept behind the system is this: you give it text written in your favorite markup language, be that Markdown, Textile, or just plain HTML, and it churns that through a layout or series of layout files. Throughout that process you can tweak how you want the site URLs to look, what data gets displayed on the layout and more. This is all done through strictly editing files, and the web interface is the final product.

A basic Jekyll site usually looks something like this:

|-- _config.yml
|-- _layouts
|   |-- default.html
|   `-- post.html
|-- _posts
|   |-- 2007-10-29-why-every-programmer-should-play-nethack.textile
|   `-- 2009-04-26-barcamp-boston-4-roundup.textile
|-- _site
`-- index.html

An overview of what each of these does:


Stores configuration data. A majority of these options can be specified from the command line exectuable but it’s easier to throw them in here so you don’t have to remember them.


These are the templates which posts are inserted into. Layouts are defined on a post-by-post basis in the YAML front matter, which is described in the next section. The liquid tag {{ content }} is used to inject data onto the page.


Your dynamic content, so to speak. The format of these files is important, as named as YEAR-MONTH-DATE-title.MARKUP. The Permalinks can be adjusted very flexibly for each post, but the date and markup language are determined solely by the file name.


This is where the generated site will be placed once Jekyll is done transforming it. It’s probably a good idea to add this to your .gitignore file.


Granted that this file has a YAML Front Matter section, it will be transformed by Jekyll. The same will happen for any .html, .markdown, or .textile file in your site’s root directory.

Other Files/Folders

Every other directory and file except for those listed above will be transferred over as expected. For example, you could have a css folder, a favicon.ico, etc, etc. There’s plenty of sites already using Jekyll if you’re curious as to how they’re laid out.

Any files in these directories will be parsed and transformed, according to the same rules mentioned previously for files in the root directory.

Running Jekyll

Usually this is done through the jekyll executable, which is installed with the gem. In order to get a server up and running with your Jekyll site, run:

jekyll --server

and then browse to There’s plenty of configuration options available to you as well.

On Ubuntu, you may need to add /var/lib/gems/1.8/bin/ to your path.


Since Jekyll simply generates a folder filled with HTML files, it can be served using practically any available web server out there.

September 22, 2010

Bundler: Best way to manage your Gems

Bundler Gem

As the name itself will specify the purpose of it. Bundler gem is used to bundle all of your required ruby gems.

The bundler allows the specification of all dependencies in a separate place from the application itself. You can specify the required version of gems and its entire set of dependencies.
So while deploying your application in a server no need to install the gem from Rubyforge or etc.

Steps to follow:

1. At the root of your application, run gem install bundler

2. Create a Gemfile in the root of your application

3. Add dependencies to your Gemfile. like gem “rspec”, 1.2.3

4. At the root, run bundle install. It will install all the gems which you specified in Gemfile from the remote system. And it will create a file called Gemfile.lock. The purpose of Gemfile.lock is to get the list of gems installed and its dependencies in your app.

5. And now run bundle package. It will make a copy of your installed gems into your application path vendor/cache. It will more helpful when you are deploying your app in any other server. Cos after running bundle package, your application will look gems into vendor/cache instead of remote systems.

For more details:

%d bloggers like this: