This project is archived and is in readonly mode.

No way to use different name of session key per controller

#2382

in Rails <= 2.1


class ApplicationController < ActionController::Base
  session :session_key => 'main_session'
end
class Admin::SomeAdminController < ApplicationController
  session :session_key => 'admin_session'
end

accessing "/" uses main_session=xxxxxx for session, accessing "/admin/some_admin" uses admin_session=xxxxxx for session.

in Rails 2.3.2, no way to do like above. because ActionController::Session::AbstractStore#initialize fixes session key to @key. It is too late to change request.session_options[:key] when controller's before_filter is called.

Reported by Tietew · March 31st, 2009 @ 06:09 AM

Activity

José Valim
- Tag changed from 2.3.2, regression, session to 2.3.2, bugmash, regression, session
August 8th, 2009 @ 12:46 PM
Kamal Fariz
The session class method itself has been deprecated. Have you tried using the session_options class method instead?

August 10th, 2009 @ 07:35 AM
Tietew
AC::Base.session_options in only effective.
session_options of subclass of AC::Base does not help us.

August 10th, 2009 @ 08:58 AM
Elise Huard
-1 Don't really see where this could be useful ?

Indeed, using the session :session_key gives following warning, at boot for application_controller and at request for other controllers:

DEPRECATION WARNING: Disabling sessions for a single controller has been deprecated. Sessions are now lazy loaded. So if you don't access them, consider them off. You can still modify the session cookie options with request.session_options.

As far as i can see, request.session_options[:key] seems to change the rack.session.options for the current request, but the session used is still identified by the same secret and key, and this is not accessible from the controller, and is a constant throughout the application.

The functionality could be achieved by extra sublevel to this hierarchy (with the cookies hash containing hashes itself), but once again I'm not sure what could be gained from this.

August 15th, 2009 @ 10:36 PM
John Pignata
-1 - I don't understand the use case for this.

August 15th, 2009 @ 11:36 PM
jmoses
The common use case for this is to separate sessions for an admin-type interface/section and the front-end of the site, without being forced to build to applications.

Personally, I don't like to have my backend and frontend sessions shared, and that was never a problem when we could change sessions options per-controller. From what I gather, this is the use-case that most people are interested in.

August 15th, 2009 @ 11:42 PM
Elise Huard
is this for security ? The only way 2 sessions would be more secure than one is if one of the session ids is only transmitted over SSL. Otherwise, I still don't see the point ?

August 16th, 2009 @ 08:31 AM
Jeremy Kemper
- State changed from new to wontfix
Workaround: you can namespace your session usage with a hash instead of tracking separate session cookies.

August 16th, 2009 @ 10:06 PM