Using SessionTimeout: which actions need session data?

I would handle this using two separate before_filter actions. For example,

before_filter expire_session before_filter authenticate

expire_session - if expired reset_session authenticate - check session for some defined value (e.g. session[:user]) and act depending on whether value is initialized.

For controllers that don't require session, don't add the filter. For actions that don't require session, use except => [ :action1, :action2, ...] along with the filter.

I am not sure you will gain anything trying to detect whether an action requires session or not, besides complexity.

HTH,

-- Long http://MeandmyCity.com/ - Free online business directory for local communities http://edgesoft.ca/blog/read/2 - No-Cookie Session Support plugin for Rails

Perhaps I misunderstood your question.

A session expires after a period of inactivity. The next request will kick start the expiring process in the expire_session filter. I believe this action should just perform house cleaning, reset_session and return true (always).

The authenticate filter runs next. It may check like

if !session[:user] then   redirect_to 'login'   return false end

Note here the before filters will run before control is passed to the requested action, whatever that may be. Though, you can control which action the filters will affect by using either except => or only => options.

I hope I am talking about the same thing you are. If not sorry I can't help.

Cheers,

-- Long

Wes Gamble wrote:

Long,

I understand all of that.

Alright.

I'd like to point out that in my case, my session timeout callback method attempts to redirect_to somewhere no matter what. I have to always return _false_ from it because everything I have is protected by my authenticate filter. Since I would have a new session (created by session_timeout) and no session[:user], I would get a double render/redirect error if the session timeout callback returned true and allowed the authenticate filter to run.

The double render/redirect error is precisely why I keep the expire_session filter simple. No render/redirect whatsoever. I leave it to filters down the chain (like authenticate) to pick up on the fact that the session have expired and do something with it.

My question was about making an intelligent decision about which action to redirect_to _within_ the session timeout callback.

I was trying to say this isn't necessary if you leave that decission to the down chain filters, like authenticate. That would be my approach and I do appologize for not being more helpful.

Regards,

-- Long