View Source README

Test Status

Components and helpers for using Cloudflare Turnstile CAPTCHAs in Phoenix apps. To get started, log into the Cloudflare dashboard and visit the Turnstile tab. Add a new site with your domain name (no need to add localhost if using the default test keys), and take note of your site key and secret key. You'll need these values later.

getting-started

Getting Started

def deps do
  [
    {:phoenix_turnstile, "~> 1.0"}
  ]
end

Now add the site key and secret key to your environment variables, and configure them in config/runtime.exs:

config :phoenix_turnstile,
  site_key: System.fetch_env!("TURNSTILE_SITE_KEY"),
  secret_key: System.fetch_env!("TURNSTILE_SECRET_KEY")

You don't need to add a site key or secret key for dev/test environments. This library will use the Turnstile test keys by default.

with-live-view

With Live View

To use CAPTCHAs in a Live View app, start out by adding the script component in your root layout:

<head>
  <!-- ... -->

  <Turnstile.script />
</head>

Next, install the hook in app.js or wherever your live socket is being defined (make sure you're setting NODE_PATH in your esbuild config and including the deps folder):

import { TurnstileHook } from "phoenix_turnstile"

const liveSocket = new LiveSocket("/live", Socket, {
  /* ... */
  hooks: {
    Turnstile: TurnstileHook
  }
})

Now you can use the Turnstile widget component in any of your forms. For example:

<.form for={@form} phx-submit="submit">
  <Turnstile.widget theme="light" />

  <button type="submit">Submit</button>
</.form>

To customize the widget, pass any of the render parameters specificed here (without the data- prefix).

verification

Verification

The widget by itself won't actually complete the verification. It works by generating a token which gets injected into your form as a hidden input named cf-turnstile-response. The token needs to be sent to the Cloudflare API for final verification before continuing with the form submission. This should be done in your submit event using Turnstile.verify/2:

def handle_event("submit", values, socket) do
  case Turnstile.verify(values) do
    {:ok, _} ->
      # Verification passed!

      {:noreply, socket}

    {:error, _} ->
      socket =
        socket
        |> put_flash(:error, "Please try submitting again")
        |> Turnstile.refresh()

      {:noreply, socket}
  end
end

To be extra sure the user is not a robot, you also have the option of passing their IP address to the verification API. This step is optional. To get the user's IP address in Live View, add :peer_data to the connect info for your socket in endpoint.ex:

socket "/live", Phoenix.LiveView.Socket,
  websocket: [
    connect_info: [:peer_data, ...]
  ]

and pass it as the second argument to Turnstile.verify/2:

def mount(_params, session, socket) do
  remote_ip = get_connect_info(socket, :peer_data).address

  {:ok, assign(socket, :remote_ip, remote_ip)}
end

def handle_event("submit", values, socket) do
  case Turnstile.verify(values, socket.assigns.remote_ip) do
    # ...
  end
end

multiple-widgets

Multiple Widgets

If you want to have multiple widgets on the same page, pass a unique ID to Turnstile.widget/1, Turnstile.refresh/1, and Turnstile.remove/1.

without-live-view

Without Live View

Turnstile.script/1 and Turnstile.widget/1 both rely on client hooks, and should work in non-Live View pages as long as app.js is opening a live socket (which it should by default). Simply call Turnstile.verify/2 in the controller:

def create(conn, params) do
  case Turnstile.verify(params, conn.remote_ip) do
    {:ok, _} ->
      # Verification passed!

      redirect(conn, to: ~p"/success")

    {:error, _} ->
      conn
      |> put_flash(:error, "Please try submitting again")
      |> redirect(to: ~p"/new")
  end
end

If your page doesn't open a live socket or your're not using HEEx, you can still run Turnstile verifications by building your own client-side widget following the documentation and using Turnstile.site_key/0 to get your site key in the template:

def new(conn, _params) do
  conn
  |> assign(:site_key, Turnstile.site_key())
  |> render("new.html")
end
<form action="/create" method="POST">
  <!-- ... -->

  <div class="cf-turnstile" data-sitekey="<%= @site_key %>"></div>
  <button type="submit">Submit</button>
</form>

content-security-policies

Content Security Policies

If your site uses a content security policy, you'll need to add https://challenges.cloudflare.com to your script-src and frame-src directives. You can also add attributes to the script component such as nonce, and they will be passed through to the script tag:

<head>
  <!-- ... -->

  <Turnstile.script nonce={@script_src_nonce} />
</head>

writing-tests

Writing Tests

When testing forms that use Turnstile verification, you may or may not want to call the live API.

Although we use the test keys by default, you should consider using mocks during testing. An excellent library to consider is mox. Phoenix Turnstile exposes a behaviour that you can use to make writing your tests much easier.

To start using Mox with Phoenix Turnstile, add this to your test/test_helper.ex:

Mox.defmock(TurnstileMock, for: Turnstile.Behaviour)

Then in your config/test.exs:

config :phoenix_turnstile, adapter: TurnstileMock

To make sure you're using TurnstileMock during testing, use the adapter from the config rather than using Turnstile directly:

@turnstile Application.compile_env(:phoenix_turnstile, :adapter, Turnstile)

def handle_event("submit", values, socket) do
  case @turnstile.verify(values) do
    {:ok, _} ->
      # Verification passed!

      {:noreply, socket}

    {:error, _} ->
      socket =
        socket
        |> put_flash(:error, "Please try submitting again")
        |> @turnstile.refresh()

      {:noreply, socket}
  end
end

Now you can easily mock or stub any Turnstile function in your tests and they won't make any real API calls:

import Mox

setup do
  stub(TurnstileMock, :refresh, fn socket -> socket end)
  stub(TurnstileMock, :verify, fn _values, _remoteip -> {:ok, %{}} end)
end