Parameter Validation in Phoenix Apps

We explore a Validator pattern for APIs that leverages Ecto Changesets to form a boundary layer of data in your system and return helpful error messages to your clients.

Transcript

1. Parameter Validation In Phoenix Apps Desmond Bowe ElixirLA February 19, 2020
2. hi @desmondmonster https://empex.co http://elixirtalk.com https://payitoff.io
3. EMPEX
4. Ecto Changesets • Pretty good.
5. Ecto Changesets • you probably don't hand params off immediately to a CRUD operation • input params in your system with string keys, string dates, etc. %{"dateTime" => dt} and %{"date_time" => dt}
6. # deal with user-supplied data def handle(%{"user" => params}), do: ... # deal with system-generated data def handle(%{user: params}), do: ...
7. User-Supplied Data ☹ • you have unsanitized data in your system • you want to establish a boundary layer past which you can say things for certain about the data. • these won't be the only validations you have in your system, and Let it Crash is still a reasonable attitude • this pattern only guarantees that types are correct and provides helpful error messages to your users. Which we should all be doing :)
8. Param Validation Pattern + Context Controller Validator Render JSON params
9. Validator • ensure shape of data is correct • only known (ie, whitelisted) params are let into system • ensure required fields are present • coerce keys into atoms • coerce string values into meaningful types like DateTimes • return helpful errors Goals
10. Validator • should not perform db queries • should not have knowledge of business logic • should not know anything about the state of the system Anti-Goals did the user give us something we can operate on?
11. User-Supplied Data • the distance is not negative • the coordinates are valid • the filters are legal (ie, restaurant_type is "sushi", not 5) • ^^ aren't business logic, exactly. whether "sushi" is a valid type is for elsewhere in the system Finding suitable restaurants near the user
12. Param Validator defmodule Api.V1.Restaraunt.ShowNearbyParams do use Ecto.Schema import Ecto.Changeset embedded_schema do field :distance, :integer field :type_of_food, :string field :user_x, :float field :user_y, :float end @required [:distance, :type_of_food, :user_x, :user_y] def changeset(params) do __MODULE__ |> cast(params) |> validate_required(@required) |> validate_number(:distance, greater_than: 0) end end
13. Param Validator def show_nearby(conn, params) do mod = Api.V1.Restaurant.ShowNearbyParams with {:ok, validated_params} <- validate(mod, params), {:ok, user} <- show_nearby_restaurants(validated_params) do render("user.json", user: user) end end
14. Param Validator def validate_params(module, params) do cs = module.changeset(params) case cs.valid? do true -> {:ok, Ecto.Changeset.apply_changes(cs)} false -> {:error, cs} end end
15. Param Validator def show_nearby(conn, params) do mod = Api.V1.Restaurant.ShowNearbyParams with {:ok, validated_params} <- validate(mod, params), {:ok, user} <- show_nearby_restaurants(validated_params) do render("user.json", user: user) else err -> err # {:error, changeset} end end
16. Param Validator defmodule FallbackController do def call(conn, {:error, %Ecto.Changeset{} = cs}) do conn |> put_status(422) |> put_view(ErrorView) |> render("422.json", %{changeset: cs}) end end
17. Param Coercion # Api.V1.Restaurant.ShowNearbyParams def changeset(params) do __MODULE__ |> cast(coerce(params)) |> validate_required(...) end def coerce(params) do params |> coerce_x_coordinate() end def coerce_x_coordinate(%{"x" => x} = params) do Map.merge(params, %{"user_x" => x}) end def coerce_x_coordinate(params), do: params
18. Param Defaults embedded_schema do field :distance, :integer, default: 5 field :type_of_food, :string field :user_x, :float field :user_y, :float end this can help the user out if you want to assume a reasonable default
19. Notes • 1:1 mapping of controller action <> param module • these modules don’t change much • avoid the temptation to get clever with macros • easy to customize error messages • fewer responsibilities for the controller Good things
20. Notes • can be verbose, add a lot of boilerplate • duplicates schema-level validation • don’t forget to do this! • what, exactly, is business logic? Less Good things
21. thanks @desmondmonster https://empex.co http://elixirtalk.com https://payitoff.io