CORSPlug 3 Sends Access-Control-Allow-Origin: * When I'm Sure I Said Otherwise

TL;DR: I inherited this and no, I’m not qualified for this work. I’m setting my allowed origins but CORSPlug says “Access-Control-Allow-Origin: *” anyway.

Here’s the deets:

elixir --version
Erlang/OTP 24 [erts-] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]
Elixir 1.14.5 (compiled with Erlang/OTP 24)


defp deps do
		{:phoenix, "~> 1.5.3"},
		{:phoenix_ecto, "~> 4.1.0"},
		{:ecto_sql, "~> 3.4.5"},
		{:postgrex, ">= 0.0.0"},
		{:phoenix_html, "~> 2.1"},
		{:phoenix_live_reload, "~> 1.0", only: :dev},
		{:plug_cowboy, "~> 2.0"},
		{:httpoison, "~> 1.7.0"},
		{:poison, ">= 0.0.0"},
		{:hound, "~> 1.0"},
		{:cors_plug, "~> 3.0"},
		{:credo, "~> 0.3", only: [:dev, :test]},
		{:jason, "~> 1.0"},
		{:ssl_verify_fun, "~> 1.1.7", override: true}

endpoint.ex (domains obfuscated)
plug CORSPlug, origin: ["", ~r/https?.*client\.edu$/]

router.ex (app name obfuscated)

defmodule ClientApp.Router do
  use ClientApp.Web, :router

  pipeline :api do
    plug :accepts, ["json"]
    plug CORSPlug

  scope "/", ClientApp do
    pipe_through :api
    resources "/contacts", ContactController, only: [:create, :show]

I’m not sure what’s causing your specific issue, but an observation:

CORSPlug calls halt when it responds to an OPTIONS request (so the first plug wins) but merges headers for other requests (so the second plug wins) - the instances in ClientApp.Endpoint and ClientApp.Router are likely to give unexpected results unless they are configured consistently. I don’t see any reason to have both.

Thank you. That’s what I get for following other convos without understanding what I’m doing. That is absolutely redundant.