grpc-web allow custom setting custom cors headers

[AleksandarFilipov]

With the introduction of grpc-web, web browsers can access the services. Given the CORS nature of web clients, they will likely be blocked if the accessing web-client is hosted separately.

Issue braked out as suggested by @polvalente see linked issue below, which also suggests a temporary workaround shown here AleksandarFilipov/grpc-elixir@feature/grpc-web-cors...grpc-web-cors-custom.

@AleksandarFilipov I think we could use the interceptors in a similar way to how Tesla modifies the current response given the result of next.(stream, req)

https://github.com/elixir-tesla/tesla/blob/master/lib/tesla/middleware/compression.ex

In this example, they decide if the resp body needs to be decompressed based on the result tuple tag. We can provide a custom interceptor that injects response headers based on a predicate MFA tuple (that receives the stream and returns true if the headers should be injected). Something like:

defmodule MyServer do
  use GRPC.Endpoint

  intercept GRPC.Interceptors.ResponseHeaders, should_inject: {__MODULE__, :"add_cors?", 1}, headers: [{"Access-Control-Allow-Origin", "*"}, {"Access-Control-Allow-Headers", "Content-Type, x-grpc-web, x-user-agent"}]

  def add_cors?(...), do: ...
end

The one thing that might need to change (I'm not that familiar with the code base yet) is that this only works if intercepts are called before stream_reply.

I'm almost sure that intercepts are only called after the reply, though. If so, we'll need to introduce something like reply_intercept that will be called right before the reply, but the overall idea remains the same.
This idea would allow us to remove the Codec from the server_headers match as well, while still allowing us to modify the headers (the whole connection, really), as we see fit.

Shall we move this into a new issue?

Originally posted by @polvalente in #206 (comment)

[polvalente]

Moving this to 0.7 because it's been too long since 0.5 and there are people depending on us releasing an update to Hex.

[aseigo]

Is there any update on this? Trying to get grpcweb working, I found that the missing part was the headers.

One of the main things missing is that by default the grpcweb code does a CORS preflight check using the OPTIONS HTTP verb, and then setting the appropriate headers.

I managed to get things working by patching grpc/server/adapters/cowboy/handler.ex to set a new is_preflight? function that is set when the HTTP verb is OPTIONS, changing the __call_rpc__ function to be called when the method is :post or :options, add a preflight version of Server.do_handle_request that only calls call_with_interceptors/4 (with nil for the request param, as there is nothing passed in that can be decoded), prevent calling the server's function on preflight (a simple check in the last closure in call_with_interceptors), and finally in server/stream.ex add a new send_reply/3 function:

  def send_reply(%{is_preflight?: true} = stream, _reply, opts) do
    do_send_reply(stream, [], opts)
  end

Essentially, it's just adding a few new code paths that don't do anything except move to the next step in the pipeline when it's a preflight chekck.

... and now I can set headers using an interceptor in the endpoint, albeit with a rather ugly call to stream.adapter.set_headers(stream.payload. Adding a set_headers(stream, headers) function to Server would make that a bit nicer, probably.

Despite the hackiness, it works, and demonstrates how few changes are actually needed to clear this hurdle. If one of the maintainers could provide a preferred direction for how to do this, I'd be happy to work up a PR for this that would be acceptable to upstream.

[polvalente]

I think this can be added to the server based on the http_transcode option:

https://github.com/elixir-grpc/grpc/blob/master/lib%2Fgrpc%2Fserver.ex#L139

Not sure if there's a server-agnostic way of doing this, but I'm ok of doing this on a per-adapter basis

[aseigo]

I don't have transcoding enabled in my Server module, and am accessing it directly via grpcweb. So relying on the http_transcode option would not be sufficient?

[polvalente]

Yeah, doesn't look like it is then. I thought transcoding would be required for this.

I wonder how we can differ between regular grpc and grpc web

[aseigo]

I wonder how we can differ between regular grpc and grpc web

They typically use slightly different encodings, which are handled already in the library via e.g. GRPC.Codec.WebText, otherwise basically identical.

GRPC.Server.Adapters.Cowboy.Handler looks at the content-type request header, and if it starts with grpc-web then it is treated as grpc-web of some sort. The codec is then added to the %Stream{} struct that gets passed around, but that isn't overly useful since grpcweb may use the Proto or the WebText codec ...

The access method (web, grpc, transcode) , based on the content-type header plus server configuration, could also be stored in the %Stream(). Combined with a helper in Server, it would be easy and reliable to differentiate what the client "actually" is.

From there, one could implement an interceptor to set headers appropriately, differentiating between grpcweb (which may need CORS support) and other cases.