Andrei Nesterov
Andrei Nesterov
With the [cuttlefish 3.0.1](https://github.com/vernemq/rebar3_cuttlefish/commit/29bb950282063bb60579a5d551755b108d912fb5) on `debian:buster` I went up to the following error: ```bash ===> Compiling _build/default/lib/edown/src/edown_doclet.erl failed _build/default/lib/edown/src/edown_doclet.erl:112:15: record context undefined _build/default/lib/edown/src/edown_doclet.erl:113:15: record context undefined _build/default/lib/edown/src/edown_doclet.erl:114:20: record context undefined...
Thanks. With the branch, I was able to pass the `edown` problem, but not that far :-) ```bash ===> Compiling apps/vmq_server/src/vmq_sysmon_handler.erl failed apps/vmq_server/src/vmq_sysmon_handler.erl:186:32: erlang:get_stacktrace/0 is removed; use the new try/catch...
It actually seems that everything has been done already. With [this commit reverted](https://github.com/vernemq/rebar3_cuttlefish/commit/29bb950282063bb60579a5d551755b108d912fb5) and with the [stackstrace disabled](https://github.com/manifest/vernemq/commit/15eb3e9b094b4466af3e4f5323defbcd6b347df7), I've managed to build and run VerneMQ on `debian:buster`. @ioolkos Does it...
I've just made a pull request for this feature. I've also changed type descriptions a bit: ``` erlang -type cors_allowed_origins() :: [binary()] | binary(). -type cors_allowed_methods() :: [binary()]. -type cors_allowed_headers()...
From the server-side perspective, we need to parse just "Origin", "Access-Control-Request-Method" and "Access-Control-Expose-Headers" headers. Other CORS headers are produced by the server. So, it looks like we should create functions:...
`match_cors_method/2` and `match_cors_headers/2` functions reduce the requested values to those which are allowed by the server. Don't know actually is it would be better then just returning a whole list...
We also need to validate that case with allowed credentials and Origin. So, the way is a little bit further: Origin header + list of allowed origins, validation of Credentials...
What shall we return to a user when we use "*" on the server and have got a value of origin header equals to "null" or it includes unknown to...
The `globally unique identifier` (an erlang reference in our case, result of parsing "null" or unknown origin representation) is a valid origin. Receiving it, we shouldn't terminate the cross-origin resource...