In the course of integrating an authentication module (Authlogic) into
my Rails app, I’ve developed the following priority:
‘If the current user makes a url request for which they are
ineligible, return the user to the page from which they made their
invalid request.’
One way to get at this is with the following two methods in the
application_controller:
def store_location
session[:return_to] = request.request_uri
end
def redirect_back_or_default(default)
redirect_to(session[:return_to] || default)
session[:return_to] = nil
end
But if I wanted to guarantee that the user was redirected back to any
action from which they made an ineligible request, I would need to
call store_location for every such controller action, which is crazy.
Is there no inexpensive way that Rails will remember every last
request (without resort to session)?
In the course of integrating an authentication module (Authlogic) into
my Rails app, I’ve developed the following priority:
‘If the current user makes a url request for which they are
ineligible, return the user to the page from which they made their
invalid request.’
One way to get at this is with the following two methods in the
application_controller:
def store_location
session[:return_to] = request.request_uri
end
def redirect_back_or_default(default)
redirect_to(session[:return_to] || default)
session[:return_to] = nil
end
But if I wanted to guarantee that the user was redirected back to any
action from which they made an ineligible request, I would need to
call store_location for every such controller action, which is crazy.
Not crazy at all. Just put it in a before_filter.
Is there no inexpensive way that Rails will remember every last
request (without resort to session)?
Putting it in the session is pretty inexpensive, and probably the right
thing to do.
@Rob - Yes, I see what you’re referring to in the Authlogic example
code. I guess I can feel comforted by that…
@Marnen, @Rob - …but isn’t reliance on session expensive, e.g., if
I’ve chosen server-side ActiveRecordStore session storage?
Um, compared to what? If the work to instantiate the session from the
database, alter a value, and write it base is your bottleneck, I’d say
you have one blazingly fast application
I wouldn’t worry about that (at least no yet). You have to load the
user info (session + User model) to check the permission anyway so you
have to hit the database.
unauthenticated users can use all app functionality up to a certain
point, when they have to register (a try-before-you-buy approach.)
So, under this approach I have to apply the require_user approach in a
before_filter for every action, not just those associated with a few
protected pages. This just seems like a lot of work. It’s like adding
a layer of authentication goo all over my app and unlike, preferably,
enabling authentication as a ‘switch’ to my app.
Lille
If you only put the before_filter :require_user on those controllers
(or scoped to :only => [:some, :actions]), then you only have the
overhead for the actions that really need a user. You can also use (I
think) skip_session to avoid all the session overhead when you have
absolutely no need for it.
I see what you’re saying, esp., given your comment:
“you have to load the user info (session + User model) to check the
permission anyway so you have to hit the database”
Unlike what I sense is anticipated by the Authlogic example code, I
take the following approach in my app:
unauthenticated users can use all app functionality up to a certain
point, when they have to register (a try-before-you-buy approach.)
So, under this approach I have to apply the require_user approach in a
before_filter for every action, not just those associated with a few
protected pages. This just seems like a lot of work. It’s like adding
a layer of authentication goo all over my app and unlike, preferably,
enabling authentication as a ‘switch’ to my app.
