I have a Grape-based API running as a rack application, using rack-cors to allow cross-origin requests, and Warden for authentication. CORS is working as expected, but not in cases where I invoke env['warden'].authenticate. In these cases, I get an "origin not allowed" response.
I believe this is due to the order of the middleware, but I'm relatively new to rack applications. I found some information describing a similar problem with an example of how to make this work in Rails, by forcing the order of the middleware using config.middleware.insert_before Warden::Manager, Rack::Cors do ... but I don't know of a non-Rails equivalent.
The following is a simplified approximation of my config.ru:
require File.expand_path('../application', __FILE__)
use Warden::Manager do |manager|
manager.default_strategies :password
end
use Rack::Cors do
allow do
origins '*'
resource '/*', :headers => :any, :methods => [:get, :post, :options, :put]
end
end
run application
I've tried swapping the order of the use directives, but either way I get same "origin not allowed" response from methods that use warden. Part of my problem is that I'm not clear on what determines the order of the middleware in rack applications.
Is my hunch that the order of the middleware is causing this problem feasible? It seems like I'm missing something fundamental. I'd like to get rack-cors and Warden to play nicely or to find another solution to allow CORS. I tried explicitly sending the Access-Control-Allow-Origin header but Warden seems to wipe that out as well.
Had exactly the same (rather annoying) thingie, ended up with doing this on my one:
on a before do block,
header 'Access-Control-Allow-Origin', '*'
header 'Access-Control-Allow-Methods', 'GET, POST, OPTIONS, PUT'
(You may want to tweak according to RACK_ENV or such...)
Seems to work. Note this is not a full CORS implementation(of course its not) but i'll wait for that rack-cors gem fix...
HTH
Related
I am trying to learn how to develop a simple web app using pure Ruby. I have a simple backend service which I created as a Sinatra app. While developing it, I noticed the frontend (a simple HTML/JS static site) would not communicate with it because of CORS policies. So I looked into how to pass headers from Sinatra.
I came across sinatra-cors. I set it up as instructed and my app looks like this (abbreviated):
require 'sinatra'
require 'sinatra/cors'
set :allow_origin, '*'
set :allow_methods, 'GET,HEAD,POST'
set :allow_headers, 'content-type,if-modified-since,access-control-allow-methods,access-control-allow-origin'
set :expose_headers, 'content-disposition'
set :allow_credentials, true
post '/' do
[...]
end
When I run it with ruby app.rb, it works perfectly. Frontend can communicate and CORS policies are observed.
Now, I want to set up the service for a production environment. For that, I want to use Puma. So with Puma, I have a config.ru which looks like this:
require File.expand_path('app', File.dirname(__FILE__))
run WebApp
and I modified my app.rb to look like this (again abbreviated):
require 'sinatra'
require 'sinatra/cors'
class WebApp < Sinatra::Application
set :allow_origin, '*'
set :allow_methods, 'GET,HEAD,POST'
set :allow_headers, 'content-type,if-modified-since,access-control-allow-methods,access-control-allow-origin'
set :expose_headers, 'content-disposition'
set :allow_credentials, true
post '/' do
[...]
end
end
basically, wrapped the app in a class, and call it from the config.ru. When I run this by running puma in the directory, the service comes up, but headers are no longer passed back. Whenever I try to hit the backend, I get:
Access to XMLHttpRequest at 'http://localhost:4567/' from origin 'null' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
This was the error I was getting before I originally set up the headers. So it seems pretty clear to me that the set parameters are being ignored.
So, this seems like a simple matter, but I have not been able to find a proper answer: How do I make Puma respect the 'set' parameters? Or alternatively, how do I achieve the same desired result?
It seems clear to me that I am missing a very simple thing, but I cannot figure out what exactly it is.
Thanks in advance!
It looks like you are just missing register Sinatra::Cors in your class.
class WebApp < Sinatra::Application
register Sinatra::Cors # Add this line.
set :allow_origin, '*'
# etc.
I'm learning Sinatra framework & developing a login system. I came across two ways of using cookies.
A simple Sinatra inbuilt way:
enable :sessions
set :session_secret, 'random-key'
This approach produces following cookie content while logged in (used session.inspect to get the output):
{"session_id"=>"6be0b9a31831604ba51114d265ba952482e0b2da6ced6c54e15ebe7f212858ca",
"tracking"=>{"HTTP_USER_AGENT"=>"b8c1e8f89eeaea0b825bed0d811f0c7678e98c74",
"HTTP_ACCEPT_ENCODING"=>"a0bfc876d68fe7aea700da5ea8925abac6f2f794",
"HTTP_ACCEPT_LANGUAGE"=>"dd065ed263c67d799f943ab6c39b55c5e008cbb5"},
"csrf"=>"b480324f510e4f391d15cee8236a8fb74a5aaa5ce2f9ad38e4dbb025a823b16e",
"name"=>"john"}
Another approach is using an encrypted cookie :
require 'sinatra'
require 'encrypted_cookie'
use Rack::Session::EncryptedCookie, :secret => "random-key"
But this approach produces following cookie content while logged in (used session.inspect here too):
{:name=>"john"}
Why enable :sessions is creating such a big cookie with all that information & why is it required (especially those HTTP_... parts?) Because Rack::Session::EncryptedCookie isn't generating any of it.
Do you think that using enable :sessions should be preferred because it has csrf token & session id? Or do you think that Rack::Session::EncryptedCookie is enough since it is encrypted?
I have following versions of gems installed :
encrypted_cookie (0.0.4)
rack (1.5.2)
rack_csrf (2.4.0)
sinatra (1.4.3)
thin (1.5.1)
Please tell me if you need more information...
Because Sinatra will use rack-protection middleware when you enable :sessions. It makes cookie bigger but more secure.
Relevant snippet:
def setup_default_middleware(builder)
builder.use ExtendedRack
builder.use ShowExceptions if show_exceptions?
builder.use Rack::MethodOverride if method_override?
builder.use Rack::Head
setup_logging builder
setup_sessions builder
setup_protection builder
end
def setup_sessions(builder)
return unless sessions?
options = {}
options[:secret] = session_secret if session_secret?
options.merge! sessions.to_hash if sessions.respond_to? :to_hash
builder.use session_store, options
end
def setup_protection(builder)
return unless protection?
options = Hash === protection ? protection.dup : {}
options = {
img_src: "'self' data:",
font_src: "'self'"
}.merge options
protect_session = options.fetch(:session) { sessions? }
options[:without_session] = !protect_session
options[:reaction] ||= :drop_session
builder.use Rack::Protection, options
end
sessions? returns true if you enable :sessions
session_store is Rack::Session::Cookie by default
The difference between Rack::Session::EncryptedCookie
That is, if you want to use Rack::Session::EncryptedCookie with rack-production, it can be easily done by:
enable :sessions
set :session_store, Rack::Session::EncryptedCookie
FYI, since encrypted_cookie is lack of some features (secret rotation, custom serializer, etc) and no longer under maintenance, I made another one to replace it.
Hope it helps.
Because Rack::Session::EncryptedCookie requires that your secret be at least 16 bits long. In the README, they recommend using OpenSSL for generating the secret, like so:
ruby -ropenssl -e "puts OpenSSL::Random.random_bytes(16).inspect"
If you open your inspector, you'll see a cookie named 'rack.session', and its contents obfuscated.
As I know, when using Rack::Session::Cookie in Sinatra, and write session_secret as an environment variable, the session which has created won't destroy after the project deploy. I think this is a risk in Single Page Application.
I am using sessions in my Facebook Canvas Application using Sinatra and Rack.
The error that occurs in Facebook Canvas is:
NoMethodError - undefined method `session' for #<Hash:0xa3ed0a0>:
/home/apoorv/.rvm/gems/ruby-1.9.2-p320/gems/sinatra-1.3.2/lib/sinatra/base.rb:170:in `session'
The problem is surely with Rack because when I run my application as follows:
ruby application.rb -p 3000
it does not display any error. I have tried installing rack version: 1.3.6 and 1.4.1, but the error persists.
I have also tried using the following code instead of enable :sessions
use Rack::Session::Cookie, :key => 'rack.session',
:domain => 'static.ak.facebook.com',
:path => '/',
:secret => 'change_me'
Do I need to upgrade/degrade to lower version of Rack or add some piece of Code to make this thing work?
edited
Also before coming across this issue I had an issue integrating my application in Facebook Canvas which was resolved by adding this line in config.ru:
set :protection, :except => [:remote_token, :frame_options]
Using env['rack.session'] instead of session[] in the POST request recieved from Facebook solved this issue. Hope this helps to solve such problems
Though it has not fully resolved complications because, now adding a redirect to code in the same POST callback displays: undefined method secure? error.
I have not been able to solve this issue, though what I did was to avoid the redirect thing and instead add a functionality to the controller to handle different requests.
I've successfully troubleshooted an issue with session members not being available even though they were set and would like to know why it's happening. My situation can be described as:
Sinatra app using :session.
Using oAuth to authorise users and in the process setting a :ret_url session member so that the app knows where to come back to after auth.
Server is unicorn on Cedar stack (Heroku)
This works perfectly whilst running locally but the :ret_url session member was completely disappearing from the session on Heroku. I found that if I removed this code it fixed the problem:
before do
cache_control :public, :must_revalidate, :max_age => 60
end
Question 1: I'm guessing that my cookie was being cached without the :ret_url value and that's why it was breaking?
Question 2: I was setting the session member as shown in the route condition code below, is this the wrong place to do it?
# redirect users to login if necessary
set(:auth) do |access_token|
condition do
if request.request_method == 'GET'
session[:ret_url] = request.path_info
end
redirect '/' unless user_logged_in?
end
end
I'd like to use cacheing and still have my cookie be valid.
Hard to see what is going on without knowing all details, but there is a simple rule that you are most probably violating: do not use http caching on actions that are supposed to do something (other than just show page). When http caching is on, you browser does not even try to re-load the page and renders it from browser cache.
Cookies are not cached anywhere, the only thing cache_control does is setting CacheControl http response value
In your case the best thing you can do is to add list of routes that have no-action pages to your before block:
before '/my/static/page' do
cache_control :public, :must_revalidate, :max_age => 60
end
Most probably you will have very limited set of routes where you can benefit from http caching
A chap by the name of Ari Brown (waves at Ari), who is not a member here but deserves the credit for this answer, pointed me at the right solution, which is, as per the Sinatra FAQ, to not use enable :sessions but to use Rack::Session::Cookie as per
use Rack::Session::Cookie, :key => 'rack.session',
:domain => 'foo.com',
:path => '/',
:expire_after => 2592000, # In seconds
:secret => 'change_me'
I've added this into my config.ru and all is well.
I also noticed over in this post the alternative suggestion to set :session_secret, 'change_me' and, indeed, to do this via an environment variable, namely:
$ heroku config:add SESSION_KEY=a_longish_secret_key
then in your app
enable :sessions
set :session_secret, ENV['SESSION_KEY'] || 'change_me'
Obviously you can use the environment variable strategy with the Rack::Session::Cookie approach too. That's the way I went as it offers more flexibility in configuration.
The reason these work is that the cache controller middleware is farming requests out to multiple server instances and without setting a session secret it's just making one up per server, and thus breaking the sessions.
Practically everything I am looking for is said in the title - I need to access warden user variable in test to check whether authentication worked. Another way is also possible for me, just trying to test authentication nicely :)
should "authenticate" do
post "/login", {:login => "test_login", :password => "password"}, {"HTTP_HOST" => "test.host"}
assert last_response.redirect?
assert_equal last_response.env["warden"].user.login, "test_login"
end
You can't get at the internal request environment in a rack-test-style full-stack test. If you want to verify that you've been logged in as a specific user you'll need to look at something like the redirect URL (if it redirects to a user-identifiable URL) or follow the redirect (easy with rack-test's follow_redirect! helper) and then look for evidence of the User ID in the HTML.
I would have thought that you don't really need to test Warden itself, but you will want to make sure you're providing the correct information to it, and aren't mangling it in the middleware stack.
You might find something like Cucumber handy for doing genuine form-filling and submission.
Finally, Warden has its own test helpers (which definitely work with rack-test) so you can set up a request to be logged in without having to actually run through the logging in request/redirect cycle in each test - https://github.com/hassox/warden/wiki/testing has more details.