How the Problem Manifested Itself: Using restful_authentication, I could log in fine using Firefox and Opera, but not Internet Explorer or Safari. I figured, it’s just an HTML POST, nothing special, so what could be going wrong? I started to tail my logfile, and the session#create action was working properly. It was redirecting to a protected page, signifying that the login was successful. However, there was a second redirect occurring immediately after, sending me back to the login page. Here’s a tail of the logfile:

Processing SessionsController#create (for xxx.xxx.xxx.xxxat 2008-07-11 16:09:32) [POST]
  Session ID: 8375beba8418d2f58363b1a05ea93c79
  Parameters: {"commit"=>"Log in", "action"=>"create", "controller"=>"sessions", "password"=>"xxx.xxx.xxx", "login"=>"xxx.xxx.xxx"}
  User Load (0.000701)   SELECT * FROM `users` WHERE (`users`.`login` = 'xxx.xxx.xxx') LIMIT 1
Redirected to http://xxx.xxx.xxx/dashboard
Completed in 0.00163 (611 reqs/sec) | DB: 0.00070 (42%) | 302 Found [http://xxx.xxx.xxx/session]

Processing DashboardController#index (for xxx.xxx.xxx.xxx at 2008-07-11 16:09:32) [GET]
  Session ID: 2a01076513064cce771c062a01da5e54
  Parameters: {"action"=>"index", "controller"=>"dashboard"}
Redirected to http://xxx.xxx.xxx/session/new
Filter chain halted as [#] rendered_or_redirected.
Completed in 0.00043 (2309 reqs/sec) | DB: 0.00000 (0%) | 302 Found [http://xxx.xxx.xxx/dashboard]

Processing SessionsController#new (for xxx.xxx.xxx.xxx at 2008-07-11 16:09:32) [GET]
  Session ID: c8c497cb737dbb7a5977b76ef2a38a04
  Parameters: {"action"=>"new", "controller"=>"sessions"}
Rendering template within layouts/login
Rendering sessions/new
Completed in 0.00108 (928 reqs/sec) | Rendering: 0.00099 (92%) | DB: 0.00000 (0%) | 200 OK [http://xxx.xxx.xxx/session/new]

The first thing that caught my eye was “Filter chain halted…..”. The login_required before_filter (used by restful_authentication) was failing despite the fact that I was able to successfully authenticate in the previous POST to session#create. The next thing that caught my eye was the fact that each of the three requests above has a distinct session id. This suggested to me that there was a problem with the session cookie being set. A little bit of head scratching and several google searches later, I came upon….

The Real Problem: I was accessing the site through a domain name that contained an underscore (e.g. client_app.stagingdomain.com). Why is this a problem? Well, Internet Explorer (and I suppose Safari) rejects cookies for domains that contain an underscore. Oddly enough, I found the solution on a Passenger Forum Post.

As soon as I changed the domain name through which I was accessing my staging server, the problem disappeared.