Ruby on Rails, JRuby, AWS, EC2, Exalead - Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue! Comments

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Lars Pind

2010-04-20T21:40:56Z

Here's the initializer that I've used to load the flash cookie middleware in Rails 3 that seems to get the job done:

MyApp::Application.configure do
  initializer "billing.use_flash_session_cookie_middleware" do |app|
    app.middlewares.use FlashSessionCookieMiddleware, config.session_options[:key]
  end
end

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by toy

2010-04-20T09:20:24Z

It took me some time to get it work with Rails 2.3.5 and Activerecord-Sessionstore. I put it all into one gist : identify session from Get-vars in Rails 2.3.5 using middleware and Activerecord-Sessionstore

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Patrick Berkeley

2010-04-14T05:08:49Z

Thanks! I ended up setting a constant and using it where needed.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2010-04-12T21:15:17Z

It doesn't look like getting the key has been made easy, unless I've missed something obvious from my quick scan of the code. You could try:

Rails.application.config.session_store.instance_variable_get(:@key)

Another option might be to look at the middleware stack (in config.middleware) and extract the options from the cookie middleware. Neither are particularly nice options though, so it might be best to store the key in a constant somewhere and then just pass it into the cookie options and the middleware options in your initializers.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Patrick Berkeley

2010-04-09T19:57:53Z

Hi,

How do you access ActionController::Base.session_options[:key] in Rails 3? Needed for config/application.rb:

ActionController::Dispatcher.middleware.insert_before(ActionController::Base.session_store, FlashSessionCookieMiddleware, ActionController::Base.session_options[:key])

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Michael Hasenstein

2010-03-31T08:09:39Z

I prefer to use modporter (http://github.com/actionrails/modporter) and let the webserver (Apache) handle the upload. This is especially good if one expects to get a high number of big file uploads, since it would be a huge waste to let relatively giant Rails-processes be occupied with an upload each whie actually not doing anything the whole time but waiting for the upload to complete. modporter hands the upload to Rails only when it is FINISHED.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2010-03-16T18:00:50Z

As far as I'm aware RAILS_ROOT (aka Rails.root) has always contained the path to the root of your application, the parent directory of 'app' rather than 'app' itself, and looking at the Rails 3 code it looks like this will continue (although the RAILS_ROOT constant itself has been deprecated). You can verify this by looking in the config/boot.rb script for your app where you should see something like:

RAILS_ROOT = "#{File.dirname(__FILE__)}/.." unless defined?(RAILS_ROOT)

Could it be your own app is picking up a RAILS_ROOT constant defined elsewhere?

For the content type I've always used mimetype_fu with a patched Attachment#assign method. You can achieve something similar with alias_method_chain although the latest Ruby gods may frown on you for it:

module Paperclip
  class Attachment 
    def assign_with_mimetype_fu(uploaded_file)
      uploaded_file = uploaded_file.to_file(:original) if uploaded_file.is_a?(Paperclip::Attachment)
      uploaded_file.content_type = File.mime_type?(uploaded_file.original_filename) if uploaded_file.respond_to?(:content_type) && uploaded_file.content_type.to_s.strip == 'application/octet-stream'
      assign_without_mimetype_fu(uploaded_file)
    end
    alias_method_chain :assign, :mimetype_fu
  end
end

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Evan

2010-03-16T15:12:03Z

Also, it's worth noting that Flash doesn't preserve the content_type of the uploaded image, as noted by John Nunemaker in his tutorial Uploadify and Rails 2.3.

Since I'm using a fork of Paperclip by Kennon which provides supports for automatically computing and storing image dimensions (which is a darn useful thing!), not having the content type at the time of my asset instantiation broke its "auto-dimensioning" capability... or so I think...

I've managed to work around this by doing this (in my controller):

@photo = Photo.new(params[:photo])
@photo.image_content_type = MIME::Types.type_for(@photo.image_file_name).to_s
@photo.image_width = Paperclip::Geometry.from_file(params[:photo][:image]).width.to_i
@photo.image_height = Paperclip::Geometry.from_file(params[:photo][:image]).height.to_i
@photo.save!

If anyone knows of a better way, I'd love to hear about it!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Evan

2010-03-16T13:06:26Z

I don't know if this is a change in the more recent versions of Rails or not (I'm currently running 2.3.5), but for those who have read EVERYTHING on this page, copy/pasted the supplied code verbatim, and are still getting this error:

uninitialized constant FlashSessionCookieMiddleware

Check the load path in environment.rb:

config.load_paths += %W( #{RAILS_ROOT}/app/middleware )

... which SHOULD be...

config.load_paths += %W( #{RAILS_ROOT}/middleware )

... since RAILS_ROOT is the app directory. I definitely spent a good hour banging my head against a wall with this.

Otherwise, great stuff! Thanks for the excellent write up!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Daniel Brown

2010-02-02T18:04:54Z

Just in case this helps anyone else, you need to CGI.escape the @session_key parameter being set in the cookie, otherwise it will not work on session keys which have pluses etc in them.

env['HTTPCOOKIE'] = [ @sessionkey, CGI.escape(params[@sessionkey]) ].join('=').freeze unless params[@sessionkey].nil?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2010-01-13T10:17:44Z

Seems odd that'd be missing. In case anyone's interested, the u helper is an alias for url_encode in the ERB::Util module. I wonder if url_encode is available on jruby...

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by acid

2010-01-13T00:58:14Z

For those of you, who want to use this magic in jruby on rails:

There is no u helper in jruby on rails, but u can use url_escape, see http://gist.github.com/275807

acid

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-12-21T08:53:09Z

It sounds like you're describing the same session fixation problem as Trevor Rowe: because the Flash gets a 'frozen in time' copy of the session when it is initialised it won't know about changes that might happen to the session from that point on. This would likely explain the errors you get with long running forms too.

The authenticity token is stored in the session cookie, so if for example you clear your cookies, you're likely to see an invalid authenticity token error on your next request.

I haven't yet had time to try a fix like Trevor suggests (sending back an updated cookie to JavaScript and dynamically updating the URL used by Flash), but it does sound like a winner. If you're feeling adventurous give it a go and let us know if it works :)

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Claudio Poli

2009-12-20T19:22:34Z

also, this is what I'm using: http://pastie.org/750957

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Claudio Poli

2009-12-20T19:06:25Z

Hello, problem: cookies[session_key] sometimes is blank.

try deleting the cookie from the browser and do a new request, cookies will not contain the generated value but instead it's blank; even debugging Rack Env shows that the value doesn't exists.

however the browser at the end of the request will have a full cookie in its cache.

In my uploader I'm sending the session key value, remember me token from clearance to see if the user is logged in and the authenticity token.

Now, examining the source afaik auth token and session key value aren't linked, but when the session key is nil and I send the POST request, rails throws the InvalidAuthenticityToken error.

Also there seems to be another aspect; sometimes even if the session key is there and present and sent along the request, I get InvalidAuthenticityToken, but it's not due to bad escaping issues, but probably because something expires. That's it, at the moment in my app I have "long running" forms that just stay there at user's disposal (uploadify).

Ideas? Thanks.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-12-11T16:32:34Z

Ah, more of an internationalisation problem then! Glad you got it sorted :)

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by acid

2009-12-11T16:04:14Z

Ouch! I've found my error. I'd typed the filename wrong :/ A simple

mv app/middleware/flash_session_cookie_middelware.rb app/middleware/flash_session_cookie_middleware.rb

solved the problem, thanks for your patience! :D

acid

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-12-11T15:08:52Z

It really sounds like a problem with the load paths. A few more things to try from the Rails console:

Rails.configuration.load_paths
# => what's the output?

require 'app/middleware/flash_session_cookie_middleware'
# => output?

FlashSessionCookieMiddleware
# => output?

FlashSessionCookieMiddleware.new(nil)
# => output?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by acid

2009-12-10T16:32:53Z

Hmm, interessting. I'm getting the same uninitialized Constant Error as before. Here is the ouput: http://gist.github.com/253436

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-12-09T19:31:11Z

If you fire up a Rails console and try and load the class what happens (in other words just type FlashSessionCookieMiddleware at the prompt)? What about if you try and instantiate it with FlashSessionCookieMiddleware.new(nil)?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by acid

2009-12-09T14:51:04Z

@Bertgoethals Jipp, I did. Sorry, that I didn't say that in my previous post. I thought it would be clear as I can load the middleware with " around the classname.

I also use jruby, if that's a matter.

acid

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Bertgoethals

2009-12-09T08:29:54Z

@acid Did you add app/middleware to your load path?

Add this to environment.rb

config.load_paths += %W( #{RAILS_ROOT}/app/middleware )

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by acid

2009-12-08T22:07:19Z

Hello,

many thanks for this great post! I'm trying to build it into my code, but i ran into strange "unitialized Constant: FlashSessionCookieMiddleware" Errors. I tried to circumvent this with this call:

ActionController::Dispatcher.middleware.insert_before(ActionController::Base.session_store, FlashSessionCookieMiddleware, ActionController::Base.session_options[:key])

Then it get's loaded into the middleware stack but i get a strange error about the new() Method on a string.

More info can be found here: http://bit.ly/7iLCnr

Have anybody an idea, what i could have done wrong?

acid

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Bert Goethals

2009-11-18T10:52:38Z

I fixed my previous problem. here is the gist: http://gist.github.com/237741

Basically I changed the cookie setting to:

env['HTTP_COOKIE'] = [ @session_key, ::Rack::Utils.escape(params[@session_key]) ].join('=').freeze unless params[@session_key].nil?

The escaping of the value is needed as ::Rack::Utils.parse_query unescapes the value, but the ::Rack::Request.cookie() will unescape the values as well.

I suggest adding this to the post itself.

@UVSoft Yes, your post makes total sence.

@Mirko Kirović If you send your values as extra post parameters these will not be URL encoded, and thus you should take care that the values end up as encoded in the cookie. This solution is built for passing sessions via the URL, this does not apply to the POST headers.

@Ben Reubenstein Read the manual. When adding the middleware to the stack, use your session_id as the argument, don't change the middleware :p

Hope this helps!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Bert Goethals

2009-11-17T18:00:52Z

Great article, I've been using a similar technique for a couple of months, but recently I had some users (a fixed, tiny set (not reproducible on staging machines)) getting InvalidAuthenticityToken exceptions.

So I switched to your solution; but to no avail.

I have one example session:

When asking the browser (before the request) what the session is we get: (Note the "+" sign in their that could potentially cause some problems)

BAh7CiIYdXNlcl9jcmVkZW50aWFsc19pZGkC+gQiFXVzZXJfY3JlZGVudGlhbHMiAYA3YTY3NTg2YzE3YmE2NGFhYzFhOWRjZmViOWFiZDk1NDQzYzRiMjgxNTQ5MzMzMGUwMzc0NDEzNWNhYWRkMWM2OTg4YTIxYzlhNGRiNDY2ZjY1ZGQxMGZlMGQzODQzYzNhN2M3ZjdkNDcxZDU0ZjM0Mzg5MjYxN2M3ZTFiODM0NjoQX2NzcmZfdG9rZW4iMWdLR2VQQlpCZkphdWxGNW93VVhLb2htV0VYOWdzVWVKY0EreHl0WXZCbDQ9Og9zZXNzaW9uX2lkIiU3MTQzZjIzNjI4YWZhZDliMjM4YTRkMjJmNWUzM2QxYyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOgtzdWNjZXMiKFRoZSBhbGJ1bSB3YXMgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuBjoKQHVzZWR7BjsIRg==--6cf3c4385d48b4f182be28a804923dd7d5e6dd75

This is the URI received: (notice the %2B instead of +)

users/3/albums/303/images?_younited_session=BAh7CiIYdXNlcl9jcmVkZW50aWFsc19pZGkC%2BgQiFXVzZXJfY3JlZGVudGlhbHMiAYA3YTY3NTg2YzE3YmE2NGFhYzFhOWRjZmViOWFiZDk1NDQzYzRiMjgxNTQ5MzMzMGUwMzc0NDEzNWNhYWRkMWM2OTg4YTIxYzlhNGRiNDY2ZjY1ZGQxMGZlMGQzODQzYzNhN2M3ZjdkNDcxZDU0ZjM0Mzg5MjYxN2M3ZTFiODM0NjoQX2NzcmZfdG9rZW4iMWdLR2VQQlpCZkphdWxGNW93VVhLb2htV0VYOWdzVWVKY0EreHl0WXZCbDQ9Og9zZXNzaW9uX2lkIiU3MTQzZjIzNjI4YWZhZDliMjM4YTRkMjJmNWUzM2QxYyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOgtzdWNjZXMiKFRoZSBhbGJ1bSB3YXMgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuBjoKQHVzZWR7BjsIRg%3D%3D--6cf3c4385d48b4f182be28a804923dd7d5e6dd75&authenticity_token=gKGePBZBfJaulF5owUXKohmWEX9gsUeJcA%2BxytYvBl4%3D&image%5Bdescription%5D=

The params look like this: (notice the + is fixed, duh)

{ :authenticity_tokeng => 'KGePBZBfJaulF5owUXKohmWEX9gsUeJcA+xytYvBl4=', :_younited_session => 'BAh7CiIYdXNlcl9jcmVkZW50aWFsc19pZGkC+gQiFXVzZXJfY3JlZGVudGlhbHMiAYA3YTY3NTg2YzE3YmE2NGFhYzFhOWRjZmViOWFiZDk1NDQzYzRiMjgxNTQ5MzMzMGUwMzc0NDEzNWNhYWRkMWM2OTg4YTIxYzlhNGRiNDY2ZjY1ZGQxMGZlMGQzODQzYzNhN2M3ZjdkNDcxZDU0ZjM0Mzg5MjYxN2M3ZTFiODM0NjoQX2NzcmZfdG9rZW4iMWdLR2VQQlpCZkphdWxGNW93VVhLb2htV0VYOWdzVWVKY0EreHl0WXZCbDQ9Og9zZXNzaW9uX2lkIiU3MTQzZjIzNjI4YWZhZDliMjM4YTRkMjJmNWUzM2QxYyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOgtzdWNjZXMiKFRoZSBhbGJ1bSB3YXMgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuBjoKQHVzZWR7BjsIRg==--6cf3c4385d48b4f182be28a804923dd7d5e6dd75', :image => { :description => '' } }

And the session looks like this: (notice the + is fine)

_younited_session=BAh7CiIYdXNlcl9jcmVkZW50aWFsc19pZGkC+gQiFXVzZXJfY3JlZGVudGlhbHMiAYA3YTY3NTg2YzE3YmE2NGFhYzFhOWRjZmViOWFiZDk1NDQzYzRiMjgxNTQ5MzMzMGUwMzc0NDEzNWNhYWRkMWM2OTg4YTIxYzlhNGRiNDY2ZjY1ZGQxMGZlMGQzODQzYzNhN2M3ZjdkNDcxZDU0ZjM0Mzg5MjYxN2M3ZTFiODM0NjoQX2NzcmZfdG9rZW4iMWdLR2VQQlpCZkphdWxGNW93VVhLb2htV0VYOWdzVWVKY0EreHl0WXZCbDQ9Og9zZXNzaW9uX2lkIiU3MTQzZjIzNjI4YWZhZDliMjM4YTRkMjJmNWUzM2QxYyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsGOgtzdWNjZXMiKFRoZSBhbGJ1bSB3YXMgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQuBjoKQHVzZWR7BjsIRg==--6cf3c4385d48b4f182be28a804923dd7d5e6dd75

This seems perfect to me, exactly as it should be. Yet This request created an InvalidAuthenticityToken?!

Can anyone help me out with this one?

I'm using authlogic, have no additional session/cookie values defined. This is on Rails 2.3.4 with passenger and SWFuploader.

Thx in advance.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-11-10T08:20:15Z

Yes, the newer Rails authentication tokens include ‘+’ signs which need to be URL encoded. Like @mirko we tend to do it in the view using the u helper or in JavaScript using the encodeURIComponent function.

The main thing is that you do the encoding somewhere, otherwise the ‘+’ signs are treated as spaces and then you get InvalidAuthenticityToken exceptions again, which kind of defeats the purpose of the middleware.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by UVSoft

2009-11-08T12:24:43Z

Hi!

First of all thanks for this great article, it is really useful!

I tried to use this middleware, but anyway I got InvalidAuthenticityToken exception. The behavior was strange, sometimes it worked, sometimes not. I realized that Rails could not restore user session, so new session id was generated in CookieStore middleware. I started researching and found out it was because sometimes cookie contained the plus sign (+), and after our middleware plus turned into space in CookieStore middleware.

My solution is the following:

env['HTTPCOOKIE'] = [ @sessionkey, params[@sessionkey] ].join('=').freeze unless params[@sessionkey].nil?
env['HTTPCOOKIE'] = [ @sessionkey, ERB::Util.urlencode(params[@sessionkey]) ].join('=').freeze unless params[@session_key].nil?

Does it make sense?

Thanks.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-11-02T08:19:14Z

@Ben: it sounds like you've passed the session key param wrongly in the new_asset_path_with_session_information, make sure you're using the local variable as the param key, not a string or a symbol. The second problem you mention is as Trevor describes (thanks Trevor!). I've not had a chance to look at this problem yet, but will do one day ;)

@Mirko: the need for encodeURIComponent is down to a more recent change in the way Rails generates the authenticity token: I blogged about this a little while ago.

The difference between cookies[session_key_name] and session[:session_id] is simply because they represent two different things: cookies[session_key_name] gives you the entire contents of the session cookie, session[:session_id] simply gives you the ID of the current session. Think of it as the difference between simply saying params and params[:id] - the first gives you the entire params hash, the second the value of the :id parameter.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Mirko Kirović

2009-11-02T08:06:19Z

I managed to get this working, but there is something more that bugs me.

This is taken from my view JS file:

'<%= session_key_name %>'  : '<%=u cookies[session_key_name] %>',
'authenticity_token'                   : encodeURIComponent('<%=u form_authenticity_token if protect_against_forgery? %>')

I've noticed that:

cookies[session_key_name] = BAh7BzoQX2NzcmZfdG9rZW4iMVprWlJ1cWtnUlNTYnVZRjFleHY5ZmN5YWpDRDhqUzk3R2crWStDN2d3S3M9Og9zZXNzaW9uX2lkIiVhNmFmNjhiNTE0MDM4NWVjMjQwNWMwMDM5MDJlNGZkYw%3D%3D--3f4447000a68faa73e3f206a9099d65ca6824d49

and

session[:session_id] = a6af68b5140385ec2405c003902e4fdc

Huh? Why the difference?

If I pass cookies[sessionkeyname] to middleware everything works ok with the code from my previous mail. But not with session[:session_id]

authenticity_token is invalid if supplied without encodeURIComponent()

Maybe you should update you post and shed some light on this wierd behaviour.

Maybe Rails's cookie middleware does some strange things with encoding/decoding?

Kind regards, Mirko

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Mirko Kirović

2009-11-02T08:02:09Z

Great article.

I'm sending my_appsession and authenticity token as additional post params with Uploadify, so I had to change flashsessioncookie_middleware.rb to this:

require 'rack/utils'

class FlashSessionCookieMiddleware
  def initialize(app, session_key = '_session_id')
    @app = app
    @session_key = session_key
  end

  def call(env)
    if env['HTTP_USER_AGENT'] =~ /^(Adobe|Shockwave) Flash/
      params = ::Rack::Request.new(env).params
      #params = ::Rack::Utils.parse_query(env['QUERY_STRING'])
      env['HTTP_COOKIE'] = [ @session_key, params[@session_key] ].join('=').freeze unless params[@session_key].nil?
    end
    @app.call(env)
  end
end

Now the error I am receiving is really strange to me (I got used to InvalidAuthenticityToken error):

NoMethodError (You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.length):
  app/middleware/flash_session_cookie_middleware.rb:15:in `call'
  /usr/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
  /usr/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
  /usr/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
  /usr/local/lib/ruby/1.8/webrick/server.rb:162:in `start'
  /usr/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
  /usr/local/lib/ruby/1.8/webrick/server.rb:95:in `start'
  /usr/local/lib/ruby/1.8/webrick/server.rb:92:in `each'
  /usr/local/lib/ruby/1.8/webrick/server.rb:92:in `start'
  /usr/local/lib/ruby/1.8/webrick/server.rb:23:in `start'
  /usr/local/lib/ruby/1.8/webrick/server.rb:82:in `start'

Line 15 is:
    @app.call(env)

Any ideas, because I have none?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Trevor Rowe

2009-10-07T15:30:16Z

I've noticed a nasty little side-effect using the methods described in this blog post. The flash uploader will fixate on the session you give it. If your server tries to modify the session during the upload processes the changes to the session are lost (or rather ignored).

Ben - this would explain issue #2 you are having.

A little longer explanation:

When construct the url with the session key and session in the query string, it saves that off. Each successive request to your upload action will receive the same session. Because flash is not sharing the session cookies with your browser, changes made to that session in another tab get lost. The browser will delete the session cookie, but flash is unaware. If your refresh the page where your session cookie is passed to the flash uploader then it will get the new url with the new embedded-session query string.

If this behavior is unacceptable, the only solution I can come up with involves send the new session back with every upload response, and then have javascript grab the new session and give a new url to the flash uploader before it makes its next upload request. Take care to make sure you get the right session. If you just ask for coookies[session_key] in your controller you will get the old session. You will need to after you make all of the modifications to session marshell it down into the string that would normally be sent as the cookie string. You could also just add to the rack middleware and pull the new session out of its headers.

I haven't tried this yet, any thoughts?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Ben Reubenstein

2009-09-21T18:11:23Z

Another interesting thing to note that I have not quite figured out yet:

In my old code I bypassed protectfromforgery for the upload photos action.
If I logged out of my app in another tab, I could still upload files to the app. It still took the session.
When I removed my protectfromforgery exclusion, the invalidauthenticitytoken exception was thrown.

Shouldn't the session have been invalid regardless of the invalid token?...

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Ben Reubenstein

2009-09-21T17:35:04Z

I had an existing app using swfupload for a while using some cookie hacks. Upgrading the Rails 2.3.4 with the new Rack session broke it. This article was valuable in getting it working again, but for some reason params[@sessionkey] was not pulling the value out of the hash in the middleware. I had to change it to params['sessionkey'] to pull the value. Any ideas on why this might happen? I thought it might be a Rails 2.3.4 issue, but when I took the example app out of github and moved it to 2.3.4 everything worked perfectly.

require 'rack/utils'

class FlashSessionCookieMiddleware
  def initialize(app, session_key = '_session_id')
    @app = app
    @session_key = session_key
  end

  def call(env)
    if env['HTTP_USER_AGENT'] =~ /^(Adobe|Shockwave) Flash/
      params = ::Rack::Utils.parse_query(env['QUERY_STRING'])
      env['HTTP_COOKIE'] = [ @session_key, params['session_key'] ].join('=').freeze unless params['session_key'].nil?
    end
    @app.call(env)
  end
end

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-09-06T11:36:33Z

Hi Stephen,

I made a start on a more flexible version of this middleware the other day (I'll blog about it when it's ready for use) and thought to myself "I wonder if I should allow the whole cookie to be preserved?" - so good timing with your comment and I guess the answer to my question is a definite "yes"!

Rob

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Stephen England

2009-09-03T11:47:38Z

Hi Guy's,

I haved an issue (due to upgrading thoughtbot/clearance to 8.2) where I need to access other cookies from flash. I've solved this by putting all cookies into the query string like so;

def assets_path_with_session_information
    session_key = ActionController::Base.session_options[:key]
    assets_path(request_forgery_protection_token => form_authenticity_token, :cookies => cookies)
  end

And then in the Middleware pulling them all back out again;

require 'rack/utils'

class FlashSessionCookieMiddleware
  def initialize(app, session_key = '_session_id')
    @app = app
    @session_key = session_key
  end

  def call(env)
    if env['HTTP_USER_AGENT'] =~ /^(Adobe|Shockwave) Flash/
      params = ::Rack::Utils.parse_query(env['QUERY_STRING'])
      cookies = []
      params.each_pair do |key, value|
        if key =~ /^cookie/
          cookie_key = key[8..-2]
          cookies << [ cookie_key, value ].join('=').freeze
        end
      end
      env['HTTP_COOKIE'] = cookies.join(';')
    end
    @app.call(env)
  end
end

Seems to work fine for me. Hope people find it useful :) Please let me know if there is something glaringly wrong with this ;)

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by ebuyc

2009-08-28T18:21:15Z

Ok this is what I figured out: flash / flash.now was messing the session up somehow that was from the new person / account creation. I traced it down to the cookiestore class, unmarshal(session) failed to verify the cookie. Was hitting generatesid then when the flash request failed. But then it worked from there on out. Drove me nuts because a normal login was working fine...

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-08-27T22:14:13Z

That's ok I managed to get to your pastie. Smartic.us put a nice screencast on using gists over on Vimeo which you might want to take a look at.

Looking at the code my main question was how/where the person_being_viewed object was being initialised? I'd also try tweaking the helper to maybe look a little more like this:

def person_album_photos_path_with_session_information(person_id, album_id)
  session_key = ActionController::Base.session_options[:key]
  person_album_photos_path(:person_id => person_id, 
                           :album_id => album_id, 
                           session_key => cookies[session_key], 
                           request_forgery_protection_token => form_authenticity_token,
                           :swf_uploader => 1)
end

This allows you to specify the person_id and album_id when you call the helper (removing the direct reference to the params hash), removes the person_being_viewed.id default that I was unsure of, and removes the need to do any string concatenation for the swf_uploader parameter.

I'm not sure if this will make a difference though as the rest of the helper looks fine to me. Perhaps the session data is getting mangled in the middleware instead of the helper?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by ebuyc

2009-08-26T22:19:07Z

I clearly have never posted styled code nor used gist / pastie before ... Please educate me nicely... thanks.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Poster

2009-08-26T19:45:54Z

Rob & lardawge & all: a 1000 thanks :-)

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-08-25T22:11:57Z

Hi,

If you want to post a gist or pastie up the code for your view and controller I'd be happy to take a look tomorrow and see if I can spot anything.

Rob

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by ebuyc

2009-08-25T19:26:11Z

ok recap: 302 / 406 error ff / ie respectively on a new signup, first upload attempt. A refresh and all is good. I see now that even though the :person session id is on the SWFuploader page, it is not on the first flash request which hits the before filter. Now why does this all work for a returning user? And why does it work after a refresh? Still digging, but hope this helps some other running the older restful authentication system and / or similar problems.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by ebuyc

2009-08-25T18:53:04Z

ok everything looks in order, but the digest is changing every page refresh. I assume this is correct behavior?

And now I see the problem: the initial session_key is really long, but then after a page refresh it changes to about half the length...

Any thoughts would be greatly appreciated.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by ebuyc

2009-08-25T18:10:54Z

I have this working with restful authentication and swfuploader -- THANKS! . . . But for a new user I always get a 302 (failed login check before_filter) in FF and a 406 in IE on the first attempt to upload something. One page refresh and all is better. If I don't refresh then any other links force a failed login for all other requests?!. I am just curious if anyone had any similar behavior or thoughts on the matter... thanks digging in now.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Evgeniy Dolzhenko

2009-07-22T17:44:07Z

Thank you very much, very useful writeup, successfully integrated SWFUpload with Rails 2.3.2

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-07-11T22:15:26Z

@Zubin: the middleware shouldn't be doing anything unless the request is coming from Flash - could it be something else causing the session mismatch?

@Pina: What does your form view look like?

@Tung: thanks for that, I've updated the post to include your more generic code.

Rob

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Tung Nguyen

2009-07-02T19:03:27Z

Thanks for this great post.

Ping:

This is a little more generic for everyone. We're using :memcachecachestore

ActionController::Dispatcher.middleware.insertbefore(ActionController::Base.sessionstore, FlashSessionCookieMiddleware, ActionController::Base.session_options[:key])

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Pina

2009-07-02T02:55:20Z

Hi, i had to change the middleware.insert_before because my middleware stack was a little diferente, so i changed to

ActionController::Dispatcher.middleware.insert_before(ActiveRecord::SessionStore, FlashSessionCookieMiddleware, ActionController::Base.session_options[:key])

So my stack looks like this:

use Rack::Lock
use ActionController::Failsafe
use ActionController::Reloader
use FlashSessionCookieMiddleware, "_lucy2_session"
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActiveRecord::SessionStore, #<Proc:0x024e08ac@(eval):8>
use ActionController::RewindableInput
use ActionController::ParamsParser
use Rack::MethodOverride
use Rack::Head
run ActionController::Dispatcher.new

But still i'm having the InvalidAuthenticityToken error.

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
  app/middleware/flash_session_cookie_middleware.rb:16:in `call'

I'm using rails 2.3.2 with ruby 1.8. Any thoughts?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Zubin

2009-06-04T20:50:37Z

Nice work! I'd been stuck on this for a while, but one problem remains... any others had this?

In my app, when logging in via "remember me", the sessions do not match. Logging in via the login form works. Am using thoughtbot's Clearance gem btw.

As you can see, session[:session_id] does not match the end of cookies['_myapp_session'].

I've tried this kludge but it didn't work, nor did it feel "right". session[:session_id] = cookies[session_key][-40..-1] if cookies[session_key]

--
params
Hash
{"format"=>"json", "folder"=>"/", "authenticity_token"=>"tkR0ZBNgsbx6CNoGXmn9YDgn7nBrwPjnnVM2e75NKNU=", "_myapp_session"=>"BAh7CDoQX2NzcmZfdG9rZW4iMXRrUjBaQk5nc2J4NkNOb0dYbW45WURnbjduQnJ3UGpublZNMmU3NU5LTlU9IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOg9zZXNzaW9uX2lkIiU4MTMwZmNmZDhkY2Y3MTI2ZDYwZWI0NzE3ZTllZWU3Ng==--e2363b6614cd3d678218c7e14c435c01b130c031"}
.../app/middleware/flash_session_cookie_middleware.rb
--
cookies
ActionController::CookieJar
{"_myapp_session"=>"BAh7CDoQX2NzcmZfdG9rZW4iMXRrUjBaQk5nc2J4NkNOb0dYbW45WURnbjduQnJ3UGpublZNMmU3NU5LTlU9IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOg9zZXNzaW9uX2lkIiU4MTMwZmNmZDhkY2Y3MTI2ZDYwZWI0NzE3ZTllZWU3Ng==--e2363b6614cd3d678218c7e14c435c01b130c031"}
.../app/controllers/assets_controller.rb
--
session
ActionController::Session::AbstractStore::SessionHash
{:_csrf_token=>"tkR0ZBNgsbx6CNoGXmn9YDgn7nBrwPjnnVM2e75NKNU=", "flash"=>{}, :session_id=>"8130fcfd8dcf7126d60eb4717e9eee76"}
.../app/controllers/assets_controller.rb

Any ideas?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-06-02T08:06:49Z

I’ve just added some extra information for getting this middleware working on Rails 2.3.2.

@tom: you might want to take a look as it will likely solve your InvalidAuthenticityToken errors

@david: thanks for the email with the updates!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by David North

2009-05-21T19:18:27Z

I'm pretty sure this approach doesn't work in Rails 2.3.2 because CookieStore, which is a kind of middleware too now, gets its call method called before this custom Middleware, so the contents of env['HTTP_COOKIE'] never gets processed.

I've been able to confirm that my value (after middleware processing) of env['HTTP_COOKIE'] is identical for both regular requests, and Flash ones, but for Flash the session doesn't get restored.

Perhaps there's a way to force this middleware ahead of the Rails stuff?

Thanks, David

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Tom

2009-05-18T12:51:15Z

Argh! This solution works great SOMETIMES. I haven't been able to figure out the circumstances, but sometimes when the flash posts the data I still get a InvalidAuthenticityToken. I have been able to reproduce the error and noticed that if I refresh the page over and over, eventually the session and authenticity token will work. The authenticity token doesn,t change but the session data does. I was beginning to think the issue was related to page caching, but I have verified that even a new user can experience this intermittent issue. Does anyone have any ideas of where I should look?

I am using the swfuploader with the middleware code above.

Thanks, Tom

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-05-10T15:45:53Z

@Lee: sorry I didn't see your question sooner. As you've found out Rails didn't get all of it's Rack goodness until 2.3 so and upgrade is the easiest way to take advantage of middleware like this.
Glad you got it working!
Rob

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Shih-gian Lee

2009-05-08T15:05:46Z

I upgraded to Rails 2.3 and will take a look at the example provided by David North. The error is gone. Thanks to both for the great solution!

Thanks, Lee

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by shih-gian Lee

2009-05-05T15:39:14Z

Hi Rob,

Thank you for the great solution. I am working with Ruby 1.8 and Rails 2.1. I have installed the rack via gem. But, I am getting the following error:

/Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:275:in load_missing_constant': uninitialized constant ActionController::Dispatcher (NameError) from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:467:inconst_missing' from /Users/shihgianlee/work/ror/beautifulworld/config/initializers/session_store.rb:6 from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:502:in load' from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:502:inload' from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:354:in new_constants_in' from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:502:inload' from /Library/Ruby/Gems/1.8/gems/rails-2.1.0/lib/initializer.rb:475:in load_application_initializers' from /Library/Ruby/Gems/1.8/gems/rails-2.1.0/lib/initializer.rb:474:ineach' ... 31 levels... from /Library/Ruby/Gems/1.8/gems/rails-2.1.0/lib/commands/server.rb:39 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:inrequire' from script/server:3

Any help is much appreciated.

Thanks, Lee

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-04-20T07:26:00Z

Hi David,
What about in your Rails app, if you inspect the params hash in your controller has it been mangled in some way or does it contain what it should?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by David North

2009-04-15T13:15:02Z

I still get InvalidAuthenticityToken although I've verified that the correct authenticity token is appearing in the query string params in the middleware like so:

params = ::Rack::Utils.parse_query(env['QUERY_STRING']) puts params.inspect

Which shows: {"_session_id"=>"61ff4979bdcf3d92c71ef0620c3260d5", "authenticity_token"=>"m++g6vKEMIUq7n7ZEHkrI7XIV1YKnLbLWI/ZXEpXGhk="}

Any ideas?

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-04-07T07:03:46Z

Hi Jakob,
If you mean in the new_asset_path_with_session_information helper then no they shouldn't be symbols. The session_key => ... means we want to use the name of the session key obtained from the ActionController session options (for example '_my_app_session') and the request_forgery_protection_token => ... means we want to use the name of the CSRF parameter (for example 'authenticity_token').

Hope that makes sense!
Rob

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Jakob

2009-04-06T11:37:08Z

Hi, thanks for the nice post! Just a question, shouldn't the session_key and request_forgery_protection be symbols? :session_key => ...

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by lardawge

2009-03-19T17:34:55Z

Very cool! Must have just hit google cuz I couldn't find it before... I have forked and updated a sample rails app that uses attachment_fu and swfupload to include your code. http://tiny.cc/swfuploadrailsauthentication credit goes to cameronyule for the original project... Thanks again!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-03-03T17:48:37Z

Thanks Saimon, I've updated the post.

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Saimon Moore

2009-03-03T14:11:17Z

Another little fix: http://gist.github.com/73328

Saimon

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Rob Anderton

2009-02-12T08:21:52Z

Good catch - I've updated the code to check for the session key param, thanks!

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by Yaroslav

2009-02-11T13:25:30Z

Little correction: http://gist.github.com/62006

Comment on 'Flash uploaders, Rails, cookie based sessions and CSRF: Rack Middleware to the rescue!' by yaroslav

2009-02-10T17:44:36Z

Big thanks for the writeup.