This project is archived and is in readonly mode.

#2382 ✓wontfix

No way to use different name of session key per controller

Reported by Tietew | March 31st, 2009 @ 06:09 AM | in 2.x

in Rails <= 2.1

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

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.

Comments and changes to this ticket

  • José Valim

    José Valim August 8th, 2009 @ 12:46 PM

    • Tag changed from 2.3.2, regression, session to 2.3.2, bugmash, regression, session
  • Kamal Fariz

    Kamal Fariz August 10th, 2009 @ 07:35 AM

    The session class method itself has been deprecated. Have you tried using the session_options class method instead?

  • Tietew

    Tietew August 10th, 2009 @ 08:58 AM

    AC::Base.session_options in only effective.
    session_options of subclass of AC::Base does not help us.

  • Elise Huard

    Elise Huard August 15th, 2009 @ 10:36 PM

    -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.

  • John Pignata

    John Pignata August 15th, 2009 @ 11:36 PM

    -1 - I don't understand the use case for this.

  • jmoses

    jmoses August 15th, 2009 @ 11:42 PM

    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.

  • Elise Huard

    Elise Huard August 16th, 2009 @ 08:31 AM

    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 ?

  • Jeremy Kemper

    Jeremy Kemper August 16th, 2009 @ 10:06 PM

    • State changed from “new” to “wontfix”

    Workaround: you can namespace your session usage with a hash instead of tracking separate session cookies.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>