Adding origins dynamically

[scottbarrow]

Does anyone know if there's there a way to dynamically add origins to the allowed list without having to restart the server?

Thanks

[cyu]

No, that's not functionality I had in mind when I developed it. I supposed if you could figure out how to access the middleware stack you could get to the middleware and call allow in it to add new rules. Or you can use Rack::Cors in you own middleware and store the cors middleware in env to be used further up the stack

[cyu]

Thinking about it some more that's not going to quite work - you'll probably want to create a new Rack::Cors instance on every call to make sure you set all the rules.

If you can figure out a cleaner way to do this, I'd be happy to accept a patch.

[scottbarrow]

Thanks for your input
I do however have an issue with the resource picking up a particular controller

I have
config.middleware.use Rack::Cors do
allow do
origins ''
resource '/reservations/', :headers => :any, :methods => [:get, :post]
resource '/impressions/*', :headers => :any, :methods => [:post]
end
end

here are my controllers. However the reservations resource is not being allowed, whereas the impressions resource is

Is there a way to trouble shoot this?
I assume the resource should point to the name of my controllers?

Thanks

On Sep 3, 2014, at 5:13 PM, Calvin Yu notifications@github.com wrote:

Think about it some more that's not going to quite work - you'll probably want to create a new Rack::Cors instance on call to make sure you set all the rules.

If you can figure out a cleaner way to do this, I'd be happy to accept a patch.

—
Reply to this email directly or view it on GitHub.

[cyu]

There is a way to enable some logging, but it only logs where there's a resource hit, and not misses.

That gives me an idea though - I can probably return some diagnostics in the HTTP headers to make troubleshooting these issues easier. Doesn't really help you right now though. Sorry.

[scottbarrow]

no problem
I realized that I had to also include the other resources in the path
i.e. hotels/1/room/2

i had to allow both resource room and hotel

On Sep 5, 2014, at 8:27 AM, Calvin Yu notifications@github.com wrote:

There is a way to enable some logging, but it only logs where there's a resource hit, and not misses.

That gives me an idea though - I can probably return some diagnostics in the HTTP headers to make troubleshooting these issues easier. Doesn't really help you right now though. Sorry.

—
Reply to this email directly or view it on GitHub.

[cyu]

Mind sending me your final configuration?

[scottbarrow]

config.middleware.insert_after Rails::Rack::Logger, Rack::Cors, :logger => Rails.logger do
  allow do
    origins '*'
    resource '/reservations/*', :headers => :any, :methods => [:get, :post]
    resource '/hotels/*', :headers => :any, :methods => [:get]
    resource '/impressions/*', :headers => :any, :methods => [:post]
  end
end

On Sep 6, 2014, at 7:40 PM, Calvin Yu notifications@github.com wrote:

Mind sending me your final configuration?

—
Reply to this email directly or view it on GitHub.

[cyu]

Thanks!

FYI - I committed some changes to return some diagnostic headers when debug mode is enabled: 8456a39

[scottbarrow]

Hi Calvin

Can you tell me if you have a way to expose the location in the headers?

Im getting:
jqXHR.getAllResponseHeaders()
"Content-Type: application/json; charset=utf-8
Cache-Control: max-age=0, private, must-revalidate

I’m looking to get access to the Location in the response headers

On Sep 9, 2014, at 6:41 AM, Calvin Yu notifications@github.com wrote:

Thanks!

FYI - I committed some changes to return some diagnostic headers when debug mode is enabled: 8456a39

—
Reply to this email directly or view it on GitHub.

[cyu]

I'm guessing there wasn't a location header in the response. If you're using chrome or safari you can see the headers from the inspector.

[scottbarrow]

Yeah I can see them in the browser, so I guess its not a return header issue, its more that the browser is not passing them back to the ajax done callback, which I believe is a browser issue

On Sep 10, 2014, at 3:10 PM, Calvin Yu notifications@github.com wrote:

I'm guessing there wasn't a location header in the response. If you're using chrome or safari you can see the headers from the inspector.

—
Reply to this email directly or view it on GitHub.

[faragorn]

I am not sure if this issue is still relevant, but here is the solution that worked for me:

allow do
        origins do |source, env|
          # this proc should return true or false
          # You can dynamically check the database/redis or any other storage for your origins
          Database.where('redirect_uri  ~* ?', "^#{source}").exists?
        end
        resource '/api/v0/*', headers: :any, methods: [:get, :delete, :put, :post, :options]
        resource '/api/oauth/*', headers: :any, methods: [:get, :delete, :post, :options]
      end

[scratchoo]

@faragorn is your solution supposed to check for the customers who are allowed to use the api ? I have a web widget where my customers are allowed to send post requests to my server and I would like to prevent any "not allowed" request from getting a response

[faragorn]

@medbouzid Yes, in my solution it is done dynamically, and sources are checked in the database. But generally that's what origins are for, if request origin is not listed in the origins it will not be allowed.

[MaxSandulsky]

Hi every one, sorry for the stupid question, is there a way to update list of allowed origins on fly when server is already running? I need this to be able to integrate client custom APIs.