Using java_servlet_store

[Stratos Pavlakis]

Hi all,
I need some help setting up the rails session to use the servlet session store.
I setup my JDK 1.6 (Jruby 1.7.0) Rails 3.2.6 application like :

session_store.rb
----------------------
require 'action_dispatch/session/java_servlet_store'

MyApp::Application.config.session_store :java_servlet_store

application.rb
------------------
config.action_dispatch.session_store = :java_servlet_store


However, although I get and send a JSESSIONID cookie, it doesn't work. It seems like the rack session cannot be found/synced in underlying servlet session store. I get no errors but every request creates a new session.
Any ideas? Believe its trinidad or jruby-rack issue?

Thx

[Hassan Schroeder]

On Thu, Nov 8, 2012 at 1:36 AM, Stratos Pavlakis
<pavlakis...@gmail.com> wrote:

> I setup my JDK 1.6 (Jruby 1.7.0) Rails 3.2.6 application like :
>
> session_store.rb
> ----------------------
> require 'action_dispatch/session/java_servlet_store'
>
> MyApp::Application.config.session_store :java_servlet_store
>
> application.rb
> ------------------
> config.action_dispatch.session_store = :java_servlet_store

> I get no errors but every request creates a new session.

I just added a line like this to a vanilla Rails app's session_store.rb
initializer (without either of the other changes you refer to):

MyApp::Application.config.session_store :java_servlet_store

:: and it seems to work fine.

JRuby 1.7.0, Rails 3.2.8, trinidad 1.3.5, (OSX) java version 1.6.0_37

Maybe try only specifying it in one place?

--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

[Stratos Pavlakis]

No I started with declaring it in one place and didn't work either.
I use the devise gem, and can't login since the change. I 'll look into it in this weekend. Maybe try upgrading rails from 3.2.6 to 3.2.8.
Thx

[kares]

 Hi Stratos, if the issue persist pls post at least your Gemfile/lock if possible so we can try to reproduce ...

A simple - minimal Rails app, where we can reproduce the issue, would be ideal.
Also knowing Trinidad's version you're using (since @hassan tested with an older version).
I've heard such an issue previously some weeks back - not sure if it was the same issue but similar symptoms.

K.

[Hassan Schroeder]

On Fri, Nov 9, 2012 at 10:55 PM, kares <karol...@gmail.com> wrote:

> Also knowing Trinidad's version you're using (since @hassan tested with an
> older version).

Ouch, didn't realize how down-level that gemset was :-)

Test repeated with trinidad 1.4.4, same successful result.

[Stratos Pavlakis]

Hi Hassan,

I just tried without the devise gem and it worked like a charm. So it must the be the scecific gem that invalidates the session because it expects something else in the cookie I guess.
I am trying to locate the exact problem. I ' ll keep you posted.

Thx

http://about.me/hassanschroeder
twitter: @hassan

--
Has recibido este mensaje porque estás suscrito al grupo "Rails Trinidad" de Grupos de Google.

Para publicar una entrada en este grupo, envía un correo electrónico a rails-t...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a rails-trinida...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/rails-trinidad?hl=es.

[Stratos Pavlakis]

Finally found the root of the problem and why it was reproduced only when using warden.

Well, actually when you successfully sign in with devise/warden, the method set_user inside warden/proxy.rb file is called to store the user into the session.
The following snippet is from this method:

    def set_user(user, opts = {})

      scope = (opts[:scope] ||= @config.default_scope)

      # Get the default options from the master configuration for the given scope

      opts = (@config[:scope_defaults][scope] || {}).merge(opts)

      opts[:event] ||= :set_user

      @users[scope] = user

      if opts[:store] != false && opts[:event] != :fetch

        options = env[ENV_SESSION_OPTIONS]

        options[:renew] = true if options

        session_serializer.store(user, scope)

      end

      ....

      @users[scope]

    end

The line in bold which sets the renew option is what causes jruby-rack's session_store to fail.
In jruby-rack now, the servlet session store is defined in session_store.rb and has overriden some methods from Rack::Session::Abstract::ID.
The one that matters here is the commit_session method.
I think that the problem lies in that the "renew" option isn't accurately interpreted.

# :renew (implementation dependent) will prompt the generation of a new session id, and migration of data to be referenced at the new id

the session store overrides the commit_session and instead of doing :

if options[:drop] || options[:renew]
      session_id = destroy_session(env, options[:id] || generate_sid, options)
      return [status, headers, body] unless session_id
end

it does the following:

if options[:drop] || options[:renew]

     destroy_session(env, options[:id], options)

     return [status, headers, body]

end

From what I can understand by a first look is that the servlet store, instead of destroying the session and reissuing a new copy of it, it just invalidates the underlying servlet session.
https://github.com/jruby/jruby-rack/commit/de94b634d88770cd629182f70f8cc27d2af72837

Do you think I should open an issue on jruby-rack?

Thanks a lot

[kares]

 Hi Stratos, thanks a lot, it's definitely worth opening an issue with the (great) explanation you provided.

It would be also great to mention (what version to use, how to do the signup) how to reproduce this with Device.

I'm not sure it's 100% fixable (invalidating the session is all one can do in a servlet environment) but we can certainly try ...
Even if it's not, JRuby-Rack will at least have a thread on this and might help other users when using the servlet sessions.

Trinidad can also try fix this using Tomcat's APIs ... if it's not that hard (not sure yet).

Thanks again for looking into it !

K.

[Stratos Pavlakis]

You 're welcome. I thank you for trinidad and all the jruby-rack work.

Because I come from the Java world I think it can be solved by

1. holding the session attributes in a temp map,
2. invalidate the current servlet session (session.invalidate),
3. then use session = request.getSession(true) to get a new one
4. and then reassign the attributes to that.

I 'll open the issue within the day.

Thx again