This project is archived and is in readonly mode.

#2200 ✓resolved
Kyle Maxwell

reset_session broken

Reported by Kyle Maxwell | March 10th, 2009 @ 06:47 PM | in 2.x

Between Rails 2.3.0 and Rails 2.3.1, session support became severely broken in production mode, using the cookie store. Development mode works fine.

Notably, ActionController::Base#reset_session doesn't reset session. Flash messages are not stored. Setting of session variables, followed by a redirect, is ignored.

Basically, my app uses restful_authentication in standard ways. It's unusable in production mode.

Comments and changes to this ticket

  • Kyle Maxwell

    Kyle Maxwell March 10th, 2009 @ 06:51 PM

  • daeltar

    daeltar March 17th, 2009 @ 05:28 PM

    I had problems with reset_session on 2.3.0 after uprade on 2.3.1 it got OK but on 2.3.2 it is broken again.

  • David Dollar

    David Dollar March 17th, 2009 @ 07:28 PM

    It seems like in that thread the answer is given, Rails 2.3.2 doesn't work on older versions of Passenger. What version of Passenger are you running?

  • daeltar

    daeltar March 17th, 2009 @ 09:58 PM

    passenger-2.1.2

  • Pawel

    Pawel March 18th, 2009 @ 03:47 PM

    • Tag set to “2.3.2, activerecord-store, cookie-store, reset_session, session”
    • Title changed from “session support broken ” to “reset_session broken”

    Described problem affects also ActiveRecord session store, but also in development mode.

    def login reset_session session[:user_id] = 5 redirect_to :action => 'logged_in' end

    def logged_in raise "user_if not set" unless session[:user_id] end

  • Pawel

    Pawel March 18th, 2009 @ 04:12 PM

    A workaround to allow your users to log in. Read the comment or don't use it.

    
class ApplicationController
  # This will destroy session fixation protection of your authentication system.
  # Use it only if you understand the risk.
  def reset_session
    session[:lazy_load_session]
    session.reject! { true } # clear session variables but don't assign new session id
  end
end
  • Fjan

    Fjan March 18th, 2009 @ 04:23 PM

    Another workaround is to simply replace reset_session with

    session.clear

    (you may need to lazy load the session with session[:load] if you haven't used it yet)

  • Dominique Brezinski

    Dominique Brezinski March 19th, 2009 @ 11:46 PM

    If you are using ActiveRecord::SessionStore::Session (only thing I have tested it with), removing the key 'rack.session.record' from @env appears to fix the issue.

    
ActionController::Request

  def reset_session
      @env['rack.session.options'].delete(:id)
      @env.delete('rack.session.record')
      @env['rack.session'] = {}
  end

end
  • Dominique Brezinski

    Dominique Brezinski March 20th, 2009 @ 12:14 AM

    I realized further info would be helpful. The reason removing 'rack.session.record' fixes the issue is because set_session in ActiveRecord::SessionStore::Session has the following lines of code:

    
record = env[SESSION_RECORD_KEY] ||= find_session(sid)
record.data = session_data
return false unless record.save

    where

    
SESSION_RECORD_KEY = 'rack.session.record'.freeze

    sid is regenerated in get_session if it is nil, and the current sid is from

    
@env['rack.session.options'][:id]
  • Pratik

    Pratik March 22nd, 2009 @ 09:43 PM

    • Assigned user set to “josh”
  • Fjan

    Fjan March 22nd, 2009 @ 10:10 PM

    The current behaviour is not entirely unuseful: I just ran into a case where I would like to really get rid of a session, and not create a new one, as the current reset_session() does. We may want to simply use session.clear() to clear a session (and simply enhance it with lazy loading) and leave reset_session() as it is.

  • Jens

    Jens March 23rd, 2009 @ 10:35 AM

    Clearing the session doesn't protect against session fixation attacks since the session id stays the same, so just calling session.clear() is definitely not a solution for the case of a login action.

  • Fjan

    Fjan March 23rd, 2009 @ 10:45 AM

    Good point. Perhaps an optional parameter to reset_session then? Something like: reset_session(create_new=true)

  • Dominique Brezinski

    Dominique Brezinski March 23rd, 2009 @ 02:12 PM

    All session fixation preventions rely on the semantics of reset_session creating a new session id. Changing the default semantics would cause most rails apps to become vulnerable to session fixation.

    Fjan, I don't understand your desire to change reset_session. If you just want to clear the values of an existing session in your app, you can just call session.clear yourself. Changing reset_session to do what one method call already does makes no sense.

    reset_session just needs to be fixed to function as it use to, which apparently there is no current regression test for (one that tests a reset_session, add something to session, and make another request with the new session), at least not when using :active_record_store. The fix is to either have reset_session delete the one key from env or change set_session in ActiveRecord::SessionStore::Session to always find_session(sid) and not default to env[SESSION_RECORD_KEY].

  • Fjan

    Fjan March 23rd, 2009 @ 02:39 PM

    Dominique, I do not suggest that reset_session should not remove its old session_id, nor do I want to change its current definition.

    My point is that there is currently no way to avoid a new session being created and stored in the session table when you use reset_session(). (Well, the current behaviour is exactly that, but this is considered a bug). This is wasteful, for example, when a user logs out and doesn't return (It could also be considered bad behaviour to leave him with a worthless cookie if you are using the cookie store). My suggestion was to add a new option to reset_session that tells it to not create a new session after it discards the old one.

    This is the use case I ran into: I want to do a reset_session() and return an error when a spider/bot visits certain pages and I cannot do that because the new empty sessions that reset_session() generates quickly pollute the session table.

  • Dominique Brezinski

    Dominique Brezinski March 23rd, 2009 @ 05:59 PM

    Fjan, I guess I don't understand why just doing session.clear does not solve your problem? I believe your case is a feature request versus a solution to or an attribute of the bug this ticket relates to.

  • Fjan

    Fjan March 23rd, 2009 @ 06:33 PM

    Dominique: session.clear() clears the session but it does not delete it. reset_session() deletes the session but creates a new empty at the same time. So neither is a solution. Users who log out (or bots visiting my site) will all leave lots of empty sessions in the database.

    My suggestion is indeed a new feature, the reason it is appropriate to mention here is that this new "feature" is actually the current behaviour of this bug.

  • Pawel

    Pawel March 24th, 2009 @ 11:04 AM

    IMHO reset_session should be simplified to three steps: 1. Clear the session variables. 2. Remove the cookie with session_id. 3. There is no step three ;-)

    When using cookie store steps 1 and 2 can be combined into one step: delete session cookie.

    So, my point is that reset_session shouldn't create new session. New session should be created on first access to session "hash" after reset_session, just as it is lazy loaded if no session exist.

    Fjan: If you like to destroy session and don't create it just call (modified as described above) reset_session method. I'm not sure however if the session should be removed from db on reset_session call. You probably have some periodic job to delete old sessions, so why duplicate it in other place? On the other hand removing session from db would eliminate race condition I described in #2174. Still I think the solution proposed in mentioned ticket is more generic, but maybe reset_session(:store_now => true) or reset_session! could be helpful additions.

    Dominique: new reset_session behaviour would be compatible with current rails apps and will continue to provide protection against session fixation attack.

  • Fjan

    Fjan March 24th, 2009 @ 11:40 AM

    Pawel: I agree, your suggestion is better than mine. I figured that changing reset_session() to not create a new session would break applications that do flash[:notice]="You are logged out", as most do, but it is a good idea to simply create the new session at the moment the session is accessed again, that's better than creating a new option.

    BTW: I do have a cron job to delete old sessions, I just happened to have a problem with some rogue spiders lately filling up the session table at several entries a minute. (but I found anther way to solve that). Also, when you use the cookie store, it could be considered bad form to leave a worthless empty cookie on the user's computer

  • dncastilho (at gmail)

    dncastilho (at gmail) March 27th, 2009 @ 02:23 AM

    The session id also, and intermittently, mysteriously vanishes from request.session_options. I was using the session.model in rails 2.1 to put the user_id (and other information) directly in the database session table (on a separated column), for session management purposes. That is gone now, and I don't exactly understand the reason why backwards compatibility was not added from that stand point. To do the same job session.model did manually is not syntactically nice and, for the reason mentioned above, it doesn't even work.

  • eagleas

    eagleas March 27th, 2009 @ 03:40 PM

    dncastilho: Confirm. The session_options[:id] not creating again after reset_session() (old behavior), and don't created even after session[:something] access.

  • heidmo

    heidmo April 10th, 2009 @ 10:28 PM

    Test case was not checking the appropriate key and value that was set in #call_reset_session action.

    Made a #get_session_model method that will check to see if the 'rack.session.options' id is set since reset_session will nil out the the id. If the id isn't there it will go ahead and reset the model stored in 'rack.session.record'.

    The fix lives in AR session store and not in action pack.

  • heidmo

    heidmo April 13th, 2009 @ 10:09 PM

    • Tag changed from “2.3.2, activerecord-store, cookie-store, reset_session, session” to “2.3.2, activerecord-store, cookie-store, patch, reset_session, session”
  • mjf

    mjf April 14th, 2009 @ 06:57 AM

    Would that patch address the other issues of the ticket? reset_session problems aside, I'm seeing the behavior described in the original ticket:

    Setting of session variables, followed by a redirect, is ignored.

    I have essentially a fresh rails project with just the restful_authentication plugin installed. I am using Rails 2.3.2 and Passenger 2.1.3.

    I added some debugging output to ApplicationController for illustration. It just increments a counter in a before_filter and prints the session data.

    
before_filter :do_stuff

def do_stuff
  RAILS_DEFAULT_LOGGER.debug session.inspect
  session[:counter] = if session[:counter].is_a?(Fixnum) then session[:counter] + 1 else 0 end
  RAILS_DEFAULT_LOGGER.debug session.inspect
end

    When a new user is created, a flash message is set and a redirect is performed. Upon the redirect, the changes made to the session variables are lost. The before_filter output shows that the flash message is missing and the counter returns to its previous value.

    The session is evidently identified correctly, because the counter returns to its previous value instead of being reinitialized to 0.

  • heidmo

    heidmo April 14th, 2009 @ 07:17 AM

    If reset_session was called before the redirect then yes this patch would fix that issue. Otherwise, I think it's a separate issue.

  • rubynewbie

    rubynewbie April 21st, 2009 @ 10:30 PM

    Folks,

    Can someone give me a step by step instruction on what to do to fix it....

    Apologies for asking for spoon feeding but I can't seem to figure out a solution here ...

    I will really appreciate your help.

    Also, I am facing the same issue as mjf stated.

    Rajat

  • rubynewbie

    rubynewbie April 21st, 2009 @ 10:30 PM

    ps: it's driving me nuts

  • heidmo

    heidmo April 21st, 2009 @ 11:13 PM

    In the session_store.rb initializer, I monkey-patched the code with this until the patch gets pushed.

    
module ActiveRecord
  class SessionStore
    def set_session(env, sid, session_data)
      Base.silence do
        record = get_session_model(env, sid)
        record.data = session_data

        return false unless record.save
        
        session_data = record.data
        if session_data && session_data.respond_to?(:each_value)
          session_data.each_value do |obj|
            obj.clear_association_cache if obj.respond_to?(:clear_association_cache)
          end
        end
      end
      
      return true
    end
  
    def get_session_model(env, sid)
      if env[ENV_SESSION_OPTIONS_KEY][:id].nil?
        env[ENV_SESSION_OPTIONS_KEY][:id] = sid
        env[SESSION_RECORD_KEY] = find_session(sid)
      else
        env[SESSION_RECORD_KEY] ||= find_session(sid)
      end
    end
  end
end
  • Luke Pearce

    Luke Pearce May 8th, 2009 @ 12:45 PM

    Just incase anyone else has issues with flash values being lost after a redirect.

    For me it was a problem with the render_component plugin; removing it fixed the issue.

    Ta Luke

  • josh

    josh May 17th, 2009 @ 05:03 PM

    • State changed from “new” to “stale”
  • heidmo

    heidmo May 17th, 2009 @ 08:01 PM

    I'm not sure why this is stale. It's still broken so I've separated out the fail test case so you can see.

    This affects anyone try to use active record store that call reset_session.

  • heidmo

    heidmo May 17th, 2009 @ 08:32 PM

    Hey Josh,

    Here is the fix plus the test case.

    I think Dominique Brezinski kinda summed it up but to recap the only thing that gets reset in action controller is this:

      @env['rack.session.options'].delete(:id)

    And the active record session store is not checking to see if that has been cleared out or not.

    So when session_store is trying to set the new data it sets the data on the existing session record instead of the creating a new session record for the new sid(session id).

    Let me know if that make sense.
    Matt

  • Repository

    Repository May 17th, 2009 @ 08:44 PM

    • State changed from “stale” to “resolved”
  • Repository

    Repository May 17th, 2009 @ 08:44 PM

  • heidmo

    heidmo May 17th, 2009 @ 08:51 PM

    Thanks dude!

  • Bart ten Brinke

    Bart ten Brinke May 19th, 2009 @ 03:05 PM

    Is it me or is the behavior still really broken?

    reset_session should create a new session object with a new session_id and pass that to the user.
    The reason you want to do this, is because it protects people who are logging in from session attacks.

    If people log in you give them a shiny new session id with their login credentials.
    At the moment 2.3. reset_session just cleans out the data in the session object.
    This is really useless, because you need the ID to change in order to prevent session hacking.

    If you want to remove session data, session.clear will do that for you. reset_session should wipe, create a new id and then send that to the user.

    The submitted patch does not address or fix any of the above issues. Reset_session is still really broken and this could lead to unsafe rails applications.

  • heidmo

    heidmo May 19th, 2009 @ 06:25 PM

    Yeah I was thinking in abstract_store.rb in the call method on line 152 that it would generate a new sid since resest_session set the option[:id] to nil. But I don't think it is.

    sid = options[:id] || generate_sid

unless set_session(env, sid, session_data.to_hash)
  return response
end
  • Michael Kinney

    Michael Kinney October 29th, 2009 @ 03:15 PM

    I agree with Bart and Heidmo. If the desired behavior of reset_session is this:

    1. Clear the current session
    2. Assign a new empty session to the request
    3. Provide a new session ID immediately

    Then it is still broken in 2.3.4.

    I'm using ActiveRecord::SessionStore. I need the old behavior because I use the session ID for things other than storing a session. In 2.3.4, after a reset_session, the session ID is an empty string.

    Here's what I did to get around it:

    First, a quick monkey patch into ActionController::Session::AbstractStore::SessionHash

    module ActionController
  module Session
    class AbstractStore
      class SessionHash
        def invalidate!
          @loaded = false
          replace({})
        end
      end
    end
  end
end

    Then in places where I need a session ID to be available after a reset_session, I use this instead:

    def destroy_session
  request.env["HTTP_COOKIE"] = nil
  request.env["QUERY_STRING"] = nil
  request.env["rack.input"] = nil
  request.env["rack.session.record"] = nil
  request.env['rack.session'].invalidate!
end

    Why this works...

    If you were to do this from an action:

    puts session.class
reset_session
puts session.class

    You'd see that before the reset_session the class is SessionHash. Afterwards, it's a regular unadorned Hash. It has none of the session loading behaviors. I'm not even sure that values placed in it will ever make it to the session store. I didn't experiment with the plain hash after I realized that it wasn't going to do what I wanted.

    It's easy to see why, in ActionController:Request:

    def reset_session
  @env['rack.session.options'].delete(:id)
  @env['rack.session'] = {}
end

    So how to get a session to load? The SessionHash object is created in ActionController::Session::AbstractStore.call, but doesn't do anything until it's used. Then the overloaded [] and []= functions on SessionHash do "load! unless @loaded". After some twists and turns, load! will arrive at your session store class's get_session method, which is responsible for creating a new session store object and session ID if it doesn't exist.

    The trick is to be able to trigger that behavior again, so we add an invalidate! function SessionHash which "unloads" it. We also have to make sure that the next time the session is accessed it will still be a SessionHash object, so we avoid the broken reset_session and do it ourselves.

    The destroy_session function is probably overkill, but I wanted to make sure that any path by which a session ID could creep in was nullified. That means dropping the GET, POST, and any cookies that might have come in. Also, ActiveRecord::SessionStore leaves a database object in the env so we need to remove that as well. Finally, we call the new invalidate! method on the old SessionHash.

    After that, the next time the session is accessed, a load! will occur, which will result in a fresh session being created in the chosen session store.

    (First post to lighthouse, I hope I formatted everything properly.)

  • heidmo

    heidmo October 29th, 2009 @ 05:26 PM

    What about if in the get_session_model we did this instead:

      def get_session_model(env, sid)
    # check to see if reset session was called
    if env[ENV_SESSION_OPTIONS_KEY][:id].nil?
      # clear out the data from previous session to prevent hijacking
      if (record = env[SESSION_RECORD_KEY])
        record.destroy
      end
      # pass in the new sid generated from the session store
      env[ENV_SESSION_OPTIONS_KEY][:id] = sid
      env[SESSION_RECORD_KEY] = find_session(sid)
    else
      env[SESSION_RECORD_KEY] ||= find_session(sid)
    end
  end

    This code no longer keeps the session and it's data in the database once it has been reset.

  • Michael Kinney

    Michael Kinney October 29th, 2009 @ 06:13 PM

    @heidmo - I haven't tested your proposed method, but I don't think it will meet requirement #3. The real problem is that reset_session disconnects the session (as accessed from ActionController descendants) from any mechanism that could potentially generate a new session ID and session store object.

    Another idea I had that won't work: making ActionController::Request.reset_session put an empty SessionHash object in the rack env won't help, because the next access will cause a load!, which will feed the rack env to the session store's get_session, which will result in the old session being recycled.

    We need something that can invalidate the SessionHash without removing it from the rack env, while also informing any session store classes that they should not load the session ID or session objects based on anything found in the rack env.

    I do like the idea of doing a destroy in ActiveRecord::SessionStore - cuts down on stale database objects lying around waiting to be cleaned up. But anyone with a cleanup script in place won't notice anyway. My version of destroy_session includes some additional logic aimed at removing some objects from the database based on the session ID, but that isn't required.

  • Bart ten Brinke

    Bart ten Brinke November 2nd, 2009 @ 07:41 PM

    I've added a patch that tests the reset_session behaviour to make sure this won't happen in the future.

    It also shows that whatever is in the current 2-3-stable actually works, so that this ticket can be closed.

  • Michael Kinney

    Michael Kinney November 2nd, 2009 @ 08:11 PM

    @bart - That will test that reset_session supplies a new session ID when a new request comes through. The old (desired) behavior is that a new session ID should be available immediately after reset_session is called, within the same request.

    If you do this:

    puts request.session_options[:id]
reset_session
puts request.session_options[:id]

    What is expected: The first puts gives the old session ID. The second gives a fresh session ID representing an empty SessionHash object that is ready to accept new values.

    What you actually get: The first puts gives the old session ID. The second gives an empty string. The session is no longer a SessionHash object. It has been replaced by a Hash object.

  • Bart ten Brinke

    Bart ten Brinke November 2nd, 2009 @ 08:52 PM

    Okay, no closing yet, but that patch should be applied anyway.
    Can't we just generate a new ID for the session at Request.reset_session?

  • Bart ten Brinke

    Bart ten Brinke November 2nd, 2009 @ 09:14 PM

    class AbstractStore
    def regenerate_sid

    set_session(@env, generate_sid, session_data.to_hash)

    end end

    ?

  • Michael Kinney

    Michael Kinney November 2nd, 2009 @ 10:11 PM

    There's no simple way to fix this. My method only works for me because I don't care about the GET, POST, or cookies in the methods where I need reset_session. That might not be the case for someone else's app. We should preserve that information.

    Given the presence of my invalidate! method on SessionHash, here's a reset_session that uses it:

    def reset_session
  @env['rack.session.options'].delete(:id)
  @env['rack.session'].invalidate!
  @env['rack.session.options'][:requested_session_invalidated] = true
end

    With this, each session store class needs to be modified to check for that invalid flag on the env in their get_session methods. If the flag is set, don't try to load the session from the env, just make a new one. AR's session store will need to make sure to delete the model object it stashes in the env. Heidmo's method might take care of that.

  • Michael Kinney

    Michael Kinney November 2nd, 2009 @ 10:20 PM

    Re: set_session(@env, generate_sid, session_data.to_hash)

    Won't work. Example, for AR store: that will call get_session_model with a sid that doesn't exist, meaning you'll get back a new AR object with an empty data hash and a new sid. None of that stuff will make it into the env though, so you'll actually still have the old session.

  • Bart ten Brinke

    Bart ten Brinke November 3rd, 2009 @ 04:57 PM

    So why don't we implement that? Because it will throw a method missing on current active record stores that not implement that? You could catch that in the base class, throw a warning and just do a clear_session as a fallback.

  • Michael Kinney

    Michael Kinney November 3rd, 2009 @ 06:29 PM

    I haven't tried this yet, but is this basically what you're suggesting?

    def reset_session
  @env['rack.session.options'].delete(:id)
  empty_session = {}
  session_store.set_session(@env, generate_sid, empty_session)
  @env['rack.session'].replace(empty_session)
end

    generate_sid is private to AbstractStore, but otherwise that might work.

  • Bart ten Brinke

    Bart ten Brinke November 3rd, 2009 @ 07:16 PM

    Yeah, that was what the regenerate_sid was for. Is there a test somewhere in this thread that actually fails because of this behaviour?

  • Michael Kinney

    Michael Kinney November 3rd, 2009 @ 10:09 PM

    Here are some new tests. Cookie store and memcache store both pass. I can't find any tests for active record store.

    Should this be a new ticket, since this one is about cookie store and the problem is isolated to active record store?

  • Ralph Haygood

    Ralph Haygood December 1st, 2009 @ 05:28 AM

    • Assigned user changed from “josh” to “Repository”
    • Tag cleared.

    Warning: there's still a problem. I'm using Rails 2.3.5 with Ruby 1.8.6, Phusion Passenger 2.2.7, and the default (cookie) session store; the problem also exists with Rails 2.3.2 and Phusion Passenger 2.2.2. One of my controllers contains the actions

        def sign_in
      begin
        user = User.authenticate params[:email_address], params[:password]
        session[:user_id] = user.id
        ...
      rescue
        ...
      end
    end

    and

        def sign_out
      reset_session
      ...
    end

    Suppose a user first signs in, then signs out, and then tries to sign in again but mistypes his email address or password. In the second run of sign_in, user is nil, so user.id throws an exception, and the rescue clause arranges to show the user an error message. So far, so good. But it turns out the user is effectively signed in again; he can load private pages, which are guarded by a before-filter requiring a non-nil session[:user_id]. Somehow, the old session has risen from the dead. Not good at all, because of course there might be two users, a legitimate one who signs out and walks away and an illegitimate one who walks up and fools around.

    The problem disappears if "raise unless user" is inserted before "session[:user_id] = user.id" in sign_in.

    I became aware of this problem and this Lighthouse thread just this evening, and I don't have time to become familiar with the session handling machinery to the extent I suspect would be necessary to solve the problem. I generally don't comment on problems I'm not prepared to solve. But this one poses such a security risk that it seems appropriate to call attention to it.

  • Ralph Haygood

    Ralph Haygood December 1st, 2009 @ 05:34 AM

    • Tag set to “2.3.2, activerecord-store, cookie-store, patch, reset_session, session”
    • Assigned user changed from “Repository” to “josh”

    The preceding post apparently changed the "assigned user" and "tag" attributes of this thread, neither of which I had any intention of doing.

  • jimflip

    jimflip January 13th, 2010 @ 11:43 PM

    We are also seeing this in 2.3.5

    In action A we add a variable to the session then redirect_to action B, the session no longer has the variable.

    Works for us in 2.3.4

    is this deliberate or are our expectations incorrect?

    This issue seems to be marked as resolved, can someone open this?

  • Simon

    Simon February 28th, 2010 @ 11:22 PM

    I also have this problem with reset_session:

    in a before_filter i'm going into debugger mode:

    (rdb:4) session
{:expire=>Sun, 28 Feb 2010 23:13:10 UTC +00:00, :ip_address=>"127.0.0.1"}
(rdb:4) session.class
ActionController::Session::AbstractStore::SessionHash
(rdb:4) session.session_id
"d20b656744ad700d369e7fd661980d7f"
(rdb:4) reset_session
nil
(rdb:4) session.class
Hash
(rdb:4) session
{}
(rdb:4) session.class
Hash
(rdb:4) session.session_id
NoMethodError Exception: undefined method `session_id' for {}:Hash

    so why is it a normal hash afterwards? Maybe you told the anwer before but i'm not sure if i should apply any type of patch or if there is another/better solution.

  • ronin-110977 (at lighthouseapp)

    ronin-110977 (at lighthouseapp) September 9th, 2010 @ 01:15 PM

    I noticed this is an old bug, but we just upgraded our Rails version to 2.3.5 using Ruby 1.8.7 and I just came across this error. We are using the ActiveRecord store for the session.

    Is this going to be solved in a future version, or?

  • Michael Kinney

    Michael Kinney September 9th, 2010 @ 04:06 PM

    This ticket was originally about a problem with cookie store which is fixed now. Since the ticket is marked "resolved" I'm not sure if anyone else will see your message.

    There is still a problem with AR store. If you check my other responses in this ticket you can see how I worked around it in my own app.

    Good luck.

  • Jeff Kreeftmeijer

    Jeff Kreeftmeijer November 8th, 2010 @ 08:23 AM

    • Tag cleared.
    • Importance changed from “” to “Low”

    Automatic cleanup of spam.

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="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Referenced by

Pages