Error pinging presign in latest Uppy version - Preflight issue?

Not really a Shrine problem per-se and rather an Uppy one but I prefer to ask it here to Rails users like me

Well then I updated today uppy from 1.2 to the latest versions of each modules I use.
I didn’t touch my code and when pinging the presign I now get :

Started OPTIONS “/photographes/…/presign/s3/params?filename=splash%2520(19).jpg&type=image%252Fjpeg&” for ::1 at 2020-01-30 16:40:52 +0100
ActionController::RoutingError (No route matches [OPTIONS] “/photographes/…/presign/s3/params”):
actionpack ( lib/action_dispatch/middleware/debug_exceptions.rb:65:in call' web-console (3.6.2) lib/web_console/middleware.rb:135:in call_app’
web-console (3.6.2) lib/web_console/middleware.rb:30:in block in call' web-console (3.6.2) lib/web_console/middleware.rb:20:in catch’
web-console (3.6.2) lib/web_console/middleware.rb:20:in call' actionpack ( lib/action_dispatch/middleware/show_exceptions.rb:33:in call’
railties ( lib/rails/rack/logger.rb:38:in call_app' railties ( lib/rails/rack/logger.rb:26:in block in call’
activesupport ( lib/active_support/tagged_logging.rb:71:in block in tagged' activesupport ( lib/active_support/tagged_logging.rb:28:in tagged’
activesupport ( lib/active_support/tagged_logging.rb:71:in tagged' railties ( lib/rails/rack/logger.rb:26:in call’
sprockets-rails (3.2.1) lib/sprockets/rails/quiet_assets.rb:13:in call' actionpack ( lib/action_dispatch/middleware/remote_ip.rb:81:in call’
actionpack ( lib/action_dispatch/middleware/request_id.rb:27:in call' rack (2.0.8) lib/rack/method_override.rb:22:in call’
rack (2.0.8) lib/rack/runtime.rb:22:in call' activesupport ( lib/active_support/cache/strategy/local_cache_middleware.rb:29:in call’
actionpack ( lib/action_dispatch/middleware/executor.rb:14:in call' actionpack ( lib/action_dispatch/middleware/static.rb:127:in call’
rack (2.0.8) lib/rack/sendfile.rb:111:in call' railties ( lib/rails/engine.rb:524:in call’
puma (4.3.1) lib/puma/configuration.rb:228:in call' puma (4.3.1) lib/puma/server.rb:681:in handle_request’
puma (4.3.1) lib/puma/server.rb:472:in process_client' puma (4.3.1) lib/puma/server.rb:328:in block in run’
puma (4.3.1) lib/puma/thread_pool.rb:134:in `block in spawn_thread’
Started GET “/photographes/…/presign/s3/params?filename=splash%2520(19).jpg&type=image%252Fjpeg&” for ::1 at 2020-01-30 16:40:54 +0100

As you can see it tries to ping Shrine presign route with GET instead of weird OPTIONS method in the end so file is indeed uploaded. Though I am a bit curious on why this OPTIONS method first place.
Reverting to old uppy removes this error.

There is already an open issue for this -

Uppy changed to always make the OPTIONS request, so we should add a route to handle that. It isn’t causing any actual issues as far as I know.

Oh ok thanks Janko
I probably can’t do the PR but will go into Shrine code and see if I understand the presign mechanics, and also read a bit about the preflight …

I just read a bit about preflight. But I think Rails should answer every preflight with all methods available. Not too sure about that, but Rails seems to handle security at the app level (Auth Token) and by checking request content and logic, rather than method.
I guess we should setup Rack Cors in order to answer every preflight request with all methods, rather than tweaking Shrine. (but again not too sure)

I’ve just pushed a fix to master, which adds an OPTIONS route that just returns an empty successful response. If this was an actual CORS preflight request it wouldn’t be enough, but in this case it’s Uppy client explicitly making that OPTIONS request, and an empty successful response seems to work just fine.

By the way, thanks a lot for the sponsorship! :heart::green_heart::purple_heart:

Oh that’s great. I was about to implement something more global to cover any further case like but I doubt I will encounter any more similar preflight requests so I will stick to your solution.
Shrine is awesome and is a lot of work !!! I wish companies can sponsor you too maybe :+1:

1 Like