Veerasundaravel's Ruby on Rails Weblog

November 13, 2011

Localhost alternates for subdomain

Filed under: Ruby On Rails — Tags: , , , , , , , , — Veerasundaravel @ 2:04 am

Most of we Rails developers, used to check our Rails app using http://localhost:3000/. But this particular url have the  following issues.

1. We can’t add/check subdomain with localhost like http://company1.localhost:3000/

2. Some of external API will not work when we are using localhost.

3. More over using system hostname for subdomain also requires too much configuration in host files.

Best way to solve this:

smackaho.st and lvh.me provides good option of using localhost with subdomain etc. The two domains are pointed to localhost only. If we go to http://lvh.me:3000/ we’ll see the homepage of our application because lvh.me resolves to the IP address 127.0.0.1.

Checkout all the below urls. all will open your application homepage.

http://smackaho.st:3000/
http://abc.smackaho.st:3000/
http://lvh.me:3000/
http://xyz.lvh.me:3000/


Related Articles:

tbaggery – Smack a Ho.st
ASCIIcasts – Subdomain in Rails3

August 9, 2011

Rails ActionMailer – Use multipart/alternative as content_type of email


Rails uses plain/text as the default content_type for sending email, you can change it to text/html that email clients can display html formatted email.

But not all the email clients support html format well, we should make our sent emails support both plain text and html format for different email clients.

text/plain:

By default Rails sending an email with plain/text content_type, for example

# app/models/notifier.rb
def send_email(email)
  subject       email.subject
  from          email.from
  recipients    email.recipients
  sent_on       Time.now
  body          :email => email
end

# app/views/notifier/send_email.html.erb
Welcome to here: <%= link_to @email.url, @email.url %>

The sent email is a plain text email

Date: Tue, 9 Aug 2011 16:38:07 +0800
From: VeeraaWP <veeraa@wordpress.com>
To: some-user@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8

Welcome: <a href="https://veerasundaravel.wordpress.com">http://veerasundaravel.wordpress.com</a>

The link url is just displayed as a plain text because of the email content_type.

text/html:

If we want the email clients to display link url as html format, we should change the content_type to text/html.

# app/models/notifier.rb
def send_email(email)
  subject       email.subject
  from          email.from
  recipients    email.recipients
  sent_on       Time.now
  content_type     "text/html"
  body          :email => email
end

# app/views/notifier/send_email.html.erb
Welcome to here: <%= link_to @email.url, @email.url %>

Now the sent email is a html formatted email

Date: Tue, 9 Aug 2011 16:38:07 +0800
From: VeeraaWP <veeraa@wordpress.com>
To: some-user@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8

Welcome: <a href="https://veerasundaravel.wordpress.com">http://veerasundaravel.wordpress.com</a>

Now the email client can display the link url correctly with html format.

multipart/alternative:

But we can’t promise that all the email clients support the html format and some users will set the email client to display plain text email instead of html formatted email. How should we do?

We should use multipart/alternative as email content_type to support both text/plain and text/html emails.

# app/models/notifier.rb
def send_email(email)
  subject          email.subject
  from             email.from
  recipients       email.recipients
  sent_on          Time.now
  content_type     "multipart/alternative"

  part :content_type => "text/html",
    :body => render_message("send_email_html", :email => email)

  part "text/plain" do |p|
    p.body = render_message("send_email_plain", :email => email)
    p.transfer_encoding = "base64"
  end
end

# app/views/notifier/send_email_html.erb
# app/views/notifier/send_email_plain.erb

As you see, we can set the email content_type to multipart/alternative, then define content_type text/html render the file app/views/notifier/send_email_html.erb and content_type text/plain render the file app/views/notifier/send_email_plain.erb. So the sent email is as follows

Date: Tue, 9 Aug 2011 16:17:35 +0800
From: VeeraaWP <veeraa@wordpress.com>
To: some-user@gmail.com
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=mimepart_4c5a739f40ca1_967c1a0d6123

--mimepart_4c5a739f40ca1_967c1a0d6123
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: Quoted-printable
Content-Disposition: inline

Welcome: <a href="https://veerasundaravel.wordpress.com">http://veerasundaravel.wordpress.com</a>

--mimepart_4c5a739f40ca1_967c1a0d6123
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: Quoted-printable
Content-Disposition: inline

Welcome: <a href="https://veerasundaravel.wordpress.com">http://veerasundaravel.wordpress.com</a>

--mimepart_4c5a739f40ca1_967c1a0d6123--

As you see, the content_type of email is multipart/alternative now, and the body of email is divided into two parts, one is for text/plain, the other is for text/html. So email clients can decide which format of email to display.

Convention:

It’s cool, but can the codes be simpler? Of course, there is a convention to simplifier the multipart/alternative content_type

def send_email(email)
  subject          email.subject
  from             email.from
  recipients       email.recipients
  sent_on          Time.now
  body             :email => email
end

# app/views/notifier/send_email.text.plain.erb
# app/views/notifier/send_email.text.html.erb

Please note the file extensions for notifier send_email method, one is .text.plain.erb, the other is .text.html.erb, they are the email views for text/plain and text/html according to their names. ActionMailer will detect the file extension, if .text.plain and .text.html exist, the content_type of email will be set to multipart/alternative automatically.

In rails3: the mail view file names should be send_email.html.erb and send_email.text.erb


Related articles:

Rails, email and multipart/alternative (olddognewtricks.co.uk)
Rails Best Practices (rails-bestpractices.com)

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 https://www.google.com/recaptcha/admin/create. 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 => “http://gems.github.com&#8221;

Or, as a standard rails plugin:

                       script/plugin install git://github.com/ambethia/recaptcha.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!’) && @post.save
        # …
    else
        # …
    end
end


« Newer PostsOlder Posts »

%d bloggers like this: