Handle dynamic control origin for HTTP OPTIONS requests

[scottinet]

• we need a way to set up the Access-Control-Allow-Origin HTTP header ;
• when receiving an OPTIONS HTTP request, Kuzzle administrators must have a way to set the Access-Control-Allow-Origin HTTP header dynamically

The first need is already addressed: Kuzzle proxy can be configured with a custom static Access-Control-Allow-Origin value. What we don't handle is if a client need to set up this header with dynamic values for OPTIONS HTTP requests. Other requests types can already be configured through the Request.headers value.

Currently, OPTIONS requests are handled solely by Kuzzle Proxy: when it receives one, it immediately responds to the client with pre-set static headers. We need some way to allow administrators to make these headers dynamic.

Use case: we have a client with dynamic and everchanging domains, who need to send a cookie to their users, with the origin header matching the one provided during the OPTIONS request.

Proposed solution:

1. add an option in Kuzzle Proxy, asking it to send OPTIONS requests to Kuzzle instead of handling it. The data content of the request should be the default headers, as it would have been used to respond to the client directly. This option should be deactivated by default
2. in Kuzzle, add a new server:httpOptions global event, triggered each time a OPTIONS HTTP request is received, and providing default headers received from kuzzle proxy to potential plugins

[ballinette]

why an event instead of a controller's action for 2. step ?

[dbengsch]

I would map a route on OPTIONS method, it would allow to define a "default" behavior, in charge of plugins to make it dynamic when needed. And perhaps a setting to have a default behavior in proxy when dynamic behavior is not needed, to avoid the over-heap of calling Kuzzle.

[scottinet]

The problem I have with a server/httpOptions API route is that setting a "beforeAction" and a "afterAction" events is irrelevant and inconsistent

Moreover, I find it... weird, to say the least, to have a specific OPTIONS API route, and only exposed to the HTTP protocol. I mean:

• this is inconsistent with the remaining of our API
• why having a Kuzzle API route for a pure protocol handshake process?

[scottinet]

/schizophrenic mode on

This is an interesting idea if we consider a generic protocol initialization API route. Something we could call "server/handshake". There is still the problem of the before/after events though, but at least that would make some sense with protocol plugins: when connecting, a protocol plugin may decide to forward some default values to Kuzzle so that plugins may set dynamic values on the fly. Proxy's HTTP implementation would then follow the exact same process.

/schizophrenic mode off