Recent Upgrade to 2.1.0 not working IE7

rubyonrails-talk
1

I recently upgraded to Rails 2.1.0 and thought that everything worked - I work mostly in FireFox and Crome - but when I went to do testing in IE7, pretty much nothing works. I have my app broken down into about 10 seperate pages, all of which make use of auto_complete, in_place_editors, and various rails helper (and I have added all the appropriate plugins), I also have some before_filters in place for user authentication. Has anyone had problems after upgrading where IE7 starts throwing 500 errors, while every other browser works fine and how did you fix it? Thanks,

-S

2

IE throwing 500 errors?!

What do you have in your rails log? Could you post a stack trace for the 500 error you get.

Is this development or production env.

3

Some time ago, I had a problem on my project with error 500 when using IE 6/7. I think it was because I was doing $this instead of $(this) in some JavaScript. I don’t remember much more about the problem, though.

Regards, Craig

4

I'm not using $(this) anywehere, but what I did notice was that my project isn't holding any session variables, and since I make heavey use of those session variables I always get a use of a nil object error when I shouldn't. Has something changed in rails 2.1.0. in regards to session variables and how they are kept? Thanks,

-S

5

Could you share a backtrace of one of the errors that you’re seeing?

Craig

6

This is the error I get:

Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id

app/controllers/enroll_controller.rb:125:in `check_authentication' -e:4:in `load' -e:4

I know what it means but the thing is is that it shouldn't be erroring out. It is erroring out because it doesn't like this:

if @user.id != session[:user].id

It thinks that session[:user] is nil and it is, but the thing is is that it shouldn't be. The check_authentication checks to see if a user that is logged in is who they say they are. When they login the first thing that happens is that a session gets started - session[:user] - then they get redirected to the appropriate pages and the check_authentication method gets called. I can see the session variable getting set but then as we move further along in the process it disapears? And when I look in my session folder under tmp it is empty which leads me to beleive that, for whatever reason, the sessions are getting created just like they should and then immediatly destroyed.

This is wasn't a problem a week ago, but last week I upgraded to rails 2.1.0. from 1.2.? and then this started happening. So I am kinda at a loss as to what is happening and how to fix it. Thanks,

-S

7

Out of curiosity, do you have a config.action_controller.session entry in config/environment.rb? It should look something like:

config.action_controller.session = { :session_key => ‘_<your_app_name>_session’,

:secret      => '<some_long_alpha_numeric_string>'

}

Also, in Rails 2.x, the default session store is cookies:

http://ryandaigle.com/articles/2007/2/21/what-s-new-in-edge-rails-cookie-based-sessions

Regards, Craig

8

Craig Demyanovich wrote:

Out of curiosity, do you have a config.action_controller.session entry in config/environment.rb? It should look something like:

  config.action_controller.session = {     :session_key => '_<your_app_name>_session',     :secret => '<some_long_alpha_numeric_string>'   }

Also, in Rails 2.x, the default session store is cookies:

http://ryandaigle.com/articles/2007/2/21/what-s-new-in-edge-rails-cookie-based-sessions

Regards, Craig

I do have that in my envirnments.rn, however, my session_key says:

=>_newen_session

and that isn't the name of my app. My app name is new_trunk[trunk], should it be named something else?

9

I don’t know if the session_key needs to match your app name. You could change it to match and see what happens.

Craig

10

Nevermind, I don't think it's still saving any sessions. If I changed the session name to session[:dude] I got the same ol' nil refernce which says to me that it wasn't saved, although it does seem to recgonize session[:user] which is a little strange. . .