Tag Archives: Rails

I18n and Devise combination gotcha

02 Monday Feb 2015

Posted by in Ruby on Rails, Uncategorized

≈ Leave a comment

Tags

, ,

Using the Rails Internationalization (I18n) API

The Ruby I18n gem provides an easy-to-use and extensible framework for providing multiple language support in your Rails application. The process of setting up the I18n gem is quite straight forward.

The gem is already shipped with Ruby on Rails (starting with Rails 2.2), and so there is no need to include that in the Gemfile. The Rails guide gives good instructions on how to set that up and works pretty well.

There is however one hiccup I encountered in using the I18n together with the Devise gem. Not sure if this is a bug or configuration issue with Devise. The issue is this: When you sign in successfully at the login page, you get directed to the home page using the last locale.

How to reproduce the issue:

When logged in, you change the language to a different one (example fr ) and then log out. At the log in page, it shows the french version. You now select another language like English. This will change the locale to en as expected and the login page will now be the English version. However after a successful login, Devise will redirect to the root page but using the previous locale, which will be fr. In this case it gets redirected to /fr.

After studying the Devise codes, and found that by default, Devise first tries to find a valid resource_return_to key in the session, then it falls back to resource_root_path, otherwise it uses the root_path, as the after_signed_in_path.

Using logger.debug, it shows that when I change the locale in the Login page, even though the locale did changed, the  session key resource_return_to continues to point to the last signed_in_root_path. Since Devise checks the resource_return_to key first, it hence redirects to that path before it will fall back on the root_path.

The way to overcome this issue is to update the resource_return_to session key each time the locale is changed in the login page. We do this in the set_locale method in the ApplicationController.

def set_locale
   I18n.locale = params[:locale] || I18n.default_locale
   session[“user_return_to”] = signed_in_root_path(User)
end

After this Devise will redirect to the root_path for the correct locale.

I use this little hack to resolve an issue I encountered. Not sure if this is something that only occur in my Rails App environment or in the general environment. If there is someone out there who is pulling his/her hair to try to figure out the same problem, hopefully this will help you find an answer to your question.

Exim and ActionMailer in Rails Application

02 Monday Feb 2015

Posted by in Ruby on Rails, Uncategorized

≈ Leave a comment

Tags

,

For a mail server on Linux, one of the more popular ones is using the combination of Postfix and Dovecot. They provide both the incoming and outgoing mail services. And you can also set up a web mail interface for mail users. However sometimes all you need is a simple mail server that provides just the outgoing mail services. For example, mail sent out by your Rails app using ActionMailer. Even though Dove and Postfix will no doubt more than meet your need in this situation, a lightweight Mail server called Exim would be more suitable. It is easy to set up and meets the simple need of providing an outgoing mail service.

In Rails, the default mailer is the sendmail. The setting in the environment is set up that way and looks like this:

#config/environment/production.rb
 config.action_mailer.delivery_method = :sendmail
# Defaults to:
# config.action_mailer.sendmail_settings = {
#   :location => ‘/usr/sbin/sendmail’,
#   :arguments => ‘-i -t’
# }

To use Exim with Rails, it just requires a simple change in this default setting, as it behaves much like sendmail. It will look like this:

config.action_mailer.delivery_method = :sendmailconfig.action_mailer.sendmail_settings = {
  :location => ‘/usr/sbin/sendmail’,
  :arguments => ‘-i’
}

The difference is the “-t” option. Due to the fact that Exim has a different usage for the -t option, having that option as part of the sendmail default will cause Exim to fail in sending out email. The mail sent out via ActionMailer will never get sent. So to override the default setting, merely uncomment the default setting and remove the -t option.

I learned this from personal experience where I had to scratch my head to figure out why in spite of setting up everything correctly, I still did not receive the mail sent by the ActoinMailer.

For more Exim information, go to Exim

Capistrano Deployment Hiccup

26 Wednesday Nov 2014

Posted by in Ruby on Rails, Uncategorized

≈ Leave a comment

Tags

, ,

I have been using Capistrano for deployment for a few years. In general when it is properly set up, one usually have no issues. Just run a simple one line command and watch it does its magic. I use it for Rails deployment, but you may use it for other deployments as well.

On this day I had an out of usual situation where I had to restart my AWS EC2 instance. I was running out of disk space and hence needed to create a larger volume for disk space. And this requires that I stop my instance before I could detach the old volume and attach a new one. This is a pretty straight forward procedure. Except for one little inconvenience. Whenever you stop an instance and restart it, you will be given a new public IP address. I’m sure there’s way to have a fixed IP address but I’m not on that plan that provide that option. Or maybe I just did not dig deep enough to find out how to do that. You know how it is with busy programmer.

So, with a new IP address for my server certainly throw things off with my Capistrano deployment script. That should be a simple fix. Just update the IP address in that case. As a side note, I should have used a domain name in the place of an IP address. That way I just need to update my DNS record and not have to touch the script. But for a number of different reasons, which I will not dwell upon here, I used the IP address to specify my server to deploy to.

Upon running the deployment script, I encountered a deployment failure with error message as follows:

SSHKit::Runner::ExecuteError: Exception while executing on host 54.173.xx.xxx: git exit status: 1
git stdout: Nothing written
git stderr: ssh: connect to host 54.210.yy.yyy port 22: Connection timed out
error: Could not fetch origin

54.173.xx.xxx is the new IP address of my server while 54.210.yy.yyy was my old IP address. I could not figure out for hours where the old IP address came from, since I have gone through over and over again all my cap scripts to find that without any result. I googled and I hunted to see if perhaps this IP might have been cached somewhere.

After hours of searching I finally found the culprit. It was located in the repo config file on the server itself. In the application root directory you will find a repo folder which has a file called config. This config file is part of the setting for the Git. And in this file it was still using the old IP.

I don’t know exactly how the deployment flow in execution, apparently during the deployment, it was going to do a git clone from the origin. And it uses the setting in this config file on my server for the server address to do a SSH. And of course, the connection timed out.

Anyhow just to note it down here so that in case anyone encountered the same problem, you would not have to spend hours trying to track it down.