I would handle this using two separate before_filter actions. For example,
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
I am not sure you will gain anything trying to detect whether an action requires
session or not, besides complexity.
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
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
Wes Gamble wrote:
I understand all of that.
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.