Создание движка для блога с помощью Phoenix и Elixir / Часть 2. Авторизация

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

В этой части мы доработаем основу для блога, чуть глубже погрузимся в тестирование и наконец-то добавим авторизацию. Прошу прощение за небольшую задержку, далее постараюсь придерживаться чёткого расписания, либо идти на опережение!»

На данный момент наше приложение основано на:

• Elixir: v1.3.1
• Phoenix: v1.2.0
• Ecto: v2.0.2
• Comeonin: v2.5.2

Исправляем некоторые баги

Если вы следовали первой части, у вас должен быть в некоторой степени функционирующий блоговый движок, запущенный на Elixir/Phoenix. Если вы похожи на меня, то даже такая казалось бы небольшая часть проделанной работы будоражит и заставляет скорее продвигаться дальше, вызывая желание ещё больше отполировать код.

Если вы хотите следить за ходом работы, я вылил для вас весь код в репозиторий на Github.

Первый баг довольно легко воспроизвести, перейдя по адресу http://localhost:4000/sessions/new и нажав кнопку Submit. Вы должны увидеть сообщение об ошибке, похожее на:

nil given for :username, comparison with nil is forbidden as it always evaluates to false. Pass a full query expression and use is_nil/1 instead.

Если мы взглянем на функцию create в SessionController сразу станет понятно в чём дело.

def create(conn, %{"user" => user_params}) do
  user = Repo.get_by(User, username: user_params["username"])
  user
  |> sign_in(user_params["password"], conn)
end

Итак, если мы отправим в параметрах вместо username строку, содержащую пустое значение (или ничего), то получим ошибку. Давайте быстренько это поправим. К счастью, это делается легко с помощью охранных условий (guard clause) и сопоставления с образцом (pattern matching). Заменим текущую функцию create следующей:

def create(conn, %{"user" => %{"username" => username, "password" => password}})
when not is_nil(username) and not is_nil(password) do
  user = Repo.get_by(User, username: username)
  sign_in(user, password, conn)
end

def create(conn, _) do
  failed_login(conn)
end

Мы заменяем аргумент params во второй функции create нижним подчёркиванием, так как нам не нужно его нигде использовать. Мы также ссылаемся на функцию failed_login, которую нужно добавить в качестве приватной. В файле web/controllers/session_controller.ex изменим импорт Comeonin:

import Comeonin.Bcrypt, only: [checkpw: 2, dummy_checkpw: 0]

Нам нужно вызвать dummy_checkpw() так, чтобы никто не смог осуществить атаку по времени простым перебором пользователей. Далее мы добавим функцию failed_login:

defp failed_login(conn) do
  dummy_checkpw()
  conn
  |> put_session(:current_user, nil)
  |> put_flash(:error, "Invalid username/password combination!")
  |> redirect(to: page_path(conn, :index))
  |> halt()
end

Опять же, обратите внимание на вызов dummy_checkpw() вверху! Мы также очищаем нашу сессию current_user, устанавливаем flash-сообщение, говорящее пользователю о неправильном вводе логина и пароля и перенаправляем обратно на главную страницу. Под конец вызываем функцию halt, которая является разумной защитой от проблем двойного рендера. И затем весь аналогичный код заменяем вызовами нашей новой функции.

defp sign_in(user, _password, conn) when is_nil(user) do
  failed_login(conn)
end
defp sign_in(user, password, conn) do
  if checkpw(password, user.password_digest) do
    conn
    |> put_session(:current_user, %{id: user.id, username: user.username})
    |> put_flash(:info, "Sign in successful!")
    |> redirect(to: page_path(conn, :index))
  else
    failed_login(conn)
  end
end

Эти правки должны позаботиться обо всех существующих странных багах со входом, так что мы можем двигаться дальше, чтобы связать посты с добавляющими их пользователями.

Добавим миграцию

Начнём с добавления в таблицу posts ссылки на таблицу users. Для этого через Ecto-генератор создадим миграцию:

$ mix ecto.gen.migration add_user_id_to_posts

Вывод:

Compiling 1 file (.ex)
* creating priv/repo/migrations
* creating priv/repo/migrations/20160720211140_add_user_id_to_posts.exs

Если мы откроем только что созданный файл, то ничего в нём не увидим. Так что добавим в функцию change следующий код:

def change do
  alter table(:posts) do
    add :user_id, references(:users)
  end
  create index(:posts, [:user_id])
end

Этим мы добавим колонку user_id, ссылающуюся на таблицу пользователей, а также индекс для неё. Выполним команду mix ecto.migrate и приступим к редактированию наших моделей.

Связываем посты с пользователями

Давайте откроем файл web/models/post.ex и добавим ссылку на модель User. Внутрь схемы posts разместим строчку:

belongs_to :user, Pxblog.User

Нам нужно добавить в модель User обратную связь, указывающую обратно на модель Post. Внутрь схемы users в файле web/models/user.ex разместим строчку:

has_many :posts, Pxblog.Post

Нам также нужно открыть контроллер Posts и непосредственно связать посты с пользователями.

Изменяем пути

Начнём с обновления роутера, указав посты внутри пользователей. Для этого откроем файл web/router.ex и заменим пути /users и /posts на:

resources "/users", UserController do
  resources "/posts", PostController
end

Исправляем контроллер

Если мы попробуем выполнить команду mix phoenix.routes прямо сейчас, то получим ошибку. Это норма! Так как мы изменили структуру путей, то потеряли хелпер post_path, новая версия которого называется user_post_path и ссылается на вложенный ресурс. Вложенные хелперы позволяют нам получать доступ к путям, представленным ресурсами, которые требуют наличие другого ресурса (как например посты требуют наличие пользователя).

Итак, если у нас обычный хелпер post_path, мы вызываем его таким способом:

post_path(conn, :show, post)

Объект conn — это объект соединения, атом :show — это действие, на которое мы ссылаемся, а третий аргумент может мы либо моделью, либо идентификатором объекта. Отсюда у нас появляется возможность делать так:

post_path(conn, :show, 1)

В то же время, если у нас вложенный ресурс, хелперы изменятся вместе с изменением нашего файла routes. В нашем случае:

user_post_path(conn, :show, user, post)

Обратите внимание, что третий аргумент теперь представляет внешний ресурс, а каждый вложенный идёт следом.

Теперь, когда нам стало понятно почему возникают ошибки, мы можем их исправить. Нам нужно иметь доступ к запрашиваемому пользователю в каждом из действий контроллера. Лучший способ получить его — использовать плаг. Для этого откроем файл web/controllers/post_controller.ex и в самом верху добавим вызов нового плага:

plug :assign_user

А напишем мы его чуть ниже:

defp assign_user(conn, _opts) do
  case conn.params do
    %{"user_id" => user_id} ->
      user = Repo.get(Pxblog.User, user_id)
      assign(conn, :user, user)
    _ ->
      conn
  end
end

И затем везде заменим post_path на user_post_path:

def create(conn, %{"post" => post_params}) do
 changeset = Post.changeset(%Post{}, post_params)
  case Repo.insert(changeset) do
    {:ok, _post} ->
      conn
      |> put_flash(:info, "Post created successfully.")
      |> redirect(to: user_post_path(conn, :index, conn.assigns[:user]))
    {:error, changeset} ->
      render(conn, "new.html", changeset: changeset)
  end
end

def update(conn, %{"id" => id, "post" => post_params}) do
  post = Repo.get!(Post, id)
  changeset = Post.changeset(post, post_params)
  case Repo.update(changeset) do
    {:ok, post} ->
      conn
      |> put_flash(:info, "Post updated successfully.")
      |> redirect(to: user_post_path(conn, :show, conn.assigns[:user], post))
    {:error, changeset} ->
      render(conn, "edit.html", post: post, changeset: changeset)
  end
end

def delete(conn, %{"id" => id}) do
  post = Repo.get!(Post, id)
  # Здесь мы используем delete! (с восклицательным знаком), потому что мы ожидаем
  # что код всегда будет работать (иначе возникнет ошибка).
  Repo.delete!(post)
  conn
  |> put_flash(:info, "Post deleted successfully.")
  |> redirect(to: user_post_path(conn, :index, conn.assigns[:user]))
end

Приводим в порядок шаблоны

Наш контроллер перестал «выплёвывать» сообщение об ошибке, так что теперь поработаем над нашими шаблонами. Мы пошли короткой дорогой, реализовав плаг, к которому есть доступ из любого действия контроллера. Используя функцию assign на объекте соединения, мы определяем переменную, с которой сможем работать в шаблоне. Теперь немного изменим шаблоны, заменив хелпер post_path на user_post_path и убедившись, что следующий после названия действия аргумент является идентификатором пользователя. В файле web/templates/post/index.html.eex напишем:

<h2>Listing posts</h2>
<table class="table">
  <thead>
    <tr>
      <th>Title</th>
      <th>Body</th>
<th></th>
    </tr>
  </thead>
  <tbody>
<%= for post <- @posts do %>
    <tr>
      <td><%= post.title %></td>
      <td><%= post.body %></td>
<td class="text-right">
        <%= link "Show", to: user_post_path(@conn, :show, @user, post), class: "btn btn-default btn-xs" %>
        <%= link "Edit", to: user_post_path(@conn, :edit, @user, post), class: "btn btn-default btn-xs" %>
        <%= link "Delete", to: user_post_path(@conn, :delete, @user, post), method: :delete, data: [confirm: "Are you sure?"], class: "btn btn-danger btn-xs" %>
      </td>
    </tr>
<% end %>
  </tbody>
</table>
<%= link "New post", to: user_post_path(@conn, :new, @user) %>

В файле web/templates/post/show.html.eex:

<h2>Show post</h2>
<ul>
  <li>
    <strong>Title:</strong>
    <%= @post.title %>
  </li>
  <li>
    <strong>Body:</strong>
    <%= @post.body %>
  </li>
</ul>
<%= link "Edit", to: user_post_path(@conn, :edit, @user, @post) %>
<%= link "Back", to: user_post_path(@conn, :index, @user) %>

В файле web/templates/post/new.html.eex:

<h2>New post</h2>
<%= render "form.html", changeset: @changeset,
                        action: user_post_path(@conn, :create, @user) %>
<%= link "Back", to: user_post_path(@conn, :index, @user) %>

В файле web/templates/post/edit.html.eex:

<h2>Edit post</h2>
<%= render "form.html", changeset: @changeset,
                        action: user_post_path(@conn, :update, @user, @post) %>
<%= link "Back", to: user_post_path(@conn, :index, @user) %>

Теперь, в качестве проверки работоспособности, если мы запустим mix phoenix.routes, мы должны увидеть вывод путей и успешную компиляцию!

Compiling 14 files (.ex)
     page_path  GET     /                               Pxblog.PageController :index
     user_path  GET     /users                          Pxblog.UserController :index
     user_path  GET     /users/:id/edit                 Pxblog.UserController :edit
     user_path  GET     /users/new                      Pxblog.UserController :new
     user_path  GET     /users/:id                      Pxblog.UserController :show
     user_path  POST    /users                          Pxblog.UserController :create
     user_path  PATCH   /users/:id                      Pxblog.UserController :update
                PUT     /users/:id                      Pxblog.UserController :update
     user_path  DELETE  /users/:id                      Pxblog.UserController :delete
user_post_path  GET     /users/:user_id/posts           Pxblog.PostController :index
user_post_path  GET     /users/:user_id/posts/:id/edit  Pxblog.PostController :edit
user_post_path  GET     /users/:user_id/posts/new       Pxblog.PostController :new
user_post_path  GET     /users/:user_id/posts/:id       Pxblog.PostController :show
user_post_path  POST    /users/:user_id/posts           Pxblog.PostController :create
user_post_path  PATCH   /users/:user_id/posts/:id       Pxblog.PostController :update
                PUT     /users/:user_id/posts/:id       Pxblog.PostController :update
user_post_path  DELETE  /users/:user_id/posts/:id       Pxblog.PostController :delete
  session_path  GET     /sessions/new                   Pxblog.SessionController :new
  session_path  POST    /sessions                       Pxblog.SessionController :create
  session_path  DELETE  /sessions/:id                   Pxblog.SessionController :delete

Подключаем остальные части к контроллеру

Теперь, всё что нам нужно — это закончить работу над контроллером для использования новых ассоциаций. Начнём с запуска интерактивной консоли командой iex -S mix, чтобы узнать немного о том, как выбирать посты пользователей. Но перед этим нам нужно настроить список стандартных импортов/алиасов, которые будут загружаться каждый раз при загрузке консоли iex внутри нашего проекта. Создайте в корне проекта новый файл .iex.exs (обратите внимание на точку в начале имени файла) и заполните его следующим содержимым:

import Ecto.Query
alias Pxblog.User
alias Pxblog.Post
alias Pxblog.Repo
import Ecto

Теперь, при запуске iex нам не нужно каждый раз делать ничего подобного:

iex(1)> import Ecto.Query
nil
iex(2)> alias Pxblog.User
nil
iex(3)> alias Pxblog.Post
nil
iex(4)> alias Pxblog.Repo
nil
iex(5)> import Ecto
nil

Сейчас нам нужно иметь в репозитории как минимум одного пользователя. Если это не так, то добавьте его. Затем мы можем запустить:

iex(8)> user = Repo.get(User, 1)
    [debug] SELECT u0."id", u0."username", u0."email", u0."password_digest", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" = $1) [1] OK query=8.2ms
    %Pxblog.User{__meta__: #Ecto.Schema.Metadata<:loaded>, email: "test", id: 1,
     inserted_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, password: nil,
     password_confirmation: nil,
     password_digest: "$2b$12$pV/XBBCRl0RQhadQd9Y4mevOy5y0j4bCC/LjGgx7VJMosRdwme22a",
     posts: #Ecto.Association.NotLoaded<association :posts is not loaded>,
     updated_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, username: "test"}
iex(10)> Repo.all(assoc(user, :posts))
    [debug] SELECT p0."id", p0."title", p0."body", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 WHERE (p0."user_id" IN ($1)) [1] OK query=3.5ms
    []

Пока у нас не создано ни одного поста для этого пользователя, так что логично получить здесь пустой список. Мы использовали функцию assoc из Ecto, чтобы получить запрос, связывающий посты с пользователем. Мы также можем сделать следующее:

iex(14)> Repo.all from p in Post,
...(14)>          join: u in assoc(p, :user),
...(14)>          select: p
[debug] SELECT p0."id", p0."title", p0."body", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 INNER JOIN "users" AS u1 ON u1."id" = p0."user_id" [] OK query=0.9ms

Здесь создаётся запрос с inner join вместо прямого условия на выборку по идентификатору пользователя. Обратите особое внимание на то, как выглядят запросы, генерируемые в обоих случаях. Очень полезно понимать SQL, создаваемый «за кулисами» всегда, когда вы работаете с кодом, генерирующим запросы.

Мы также можем использовать функцию preload при выборке постов, чтобы предзагрузить также и пользователей, как показано ниже:

iex(18)> Repo.all(from u in User, preload: [:posts])
[debug] SELECT u0."id", u0."username", u0."email", u0."password_digest", u0."inserted_at", u0."updated_at" FROM "users" AS u0 [] OK query=0.9ms
[debug] SELECT p0."id", p0."title", p0."body", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 WHERE (p0."user_id" IN ($1)) ORDER BY p0."user_id" [1] OK query=0.8ms
iex(20)> Repo.all(from p in Post, preload: [:user])
[debug] SELECT p0."id", p0."title", p0."body", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 [] OK query=0.8ms
[]

Нам нужно добавить постов, чтобы появилась возможность повозиться с запросами. Итак, для этого мы собираемся использовать функцию Ecto под названием build_assoc. Данная функция принимает первым аргументом модель, для которой мы хотим добавить ассоциацию, и вторым — саму ассоциацию в виде атома.

iex(1)> user = Repo.get(User, 1)
iex(2)> post = build_assoc(user, :posts, %{title: "Test Title", body: "Test Body"})
iex(3)> Repo.insert(post)
iex(4)> posts = Repo.all(from p in Post, preload: [:user])

И теперь, выполнив последний запрос, мы должны получить следующий вывод:

iex(4)> posts = Repo.all(from p in Post, preload: [:user])
[debug] SELECT p0."id", p0."title", p0."body", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 [] OK query=0.7ms
[debug] SELECT u0."id", u0."username", u0."email", u0."password_digest", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" IN ($1)) [1] OK query=0.7ms
[%Pxblog.Post{__meta__: #Ecto.Schema.Metadata<:loaded>, body: "Test Body",
  id: 1, inserted_at: #Ecto.DateTime<2015-10-06T18:06:20Z>, title: "Test Title",
  updated_at: #Ecto.DateTime<2015-10-06T18:06:20Z>,
  user: %Pxblog.User{__meta__: #Ecto.Schema.Metadata<:loaded>, email: "test",
   id: 1, inserted_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, password: nil,
   password_confirmation: nil,
   password_digest: "$2b$12$pV/XBBCRl0RQhadQd9Y4mevOy5y0j4bCC/LjGgx7VJMosRdwme22a",
   posts: #Ecto.Association.NotLoaded<association :posts is not loaded>,
   updated_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, username: "test"},
  user_id: 1}]

И мы просто быстро проверим первый результат:

iex(5)> post = List.first posts
%Pxblog.Post{__meta__: #Ecto.Schema.Metadata<:loaded>, body: "Test Body", id: 1,
 inserted_at: #Ecto.DateTime<2015-10-06T18:06:20Z>, title: "Test Title",
 updated_at: #Ecto.DateTime<2015-10-06T18:06:20Z>,
 user: %Pxblog.User{__meta__: #Ecto.Schema.Metadata<:loaded>, email: "test",
  id: 1, inserted_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, password: nil,
  password_confirmation: nil,
  password_digest: "$2b$12$pV/XBBCRl0RQhadQd9Y4mevOy5y0j4bCC/LjGgx7VJMosRdwme22a",
  posts: #Ecto.Association.NotLoaded<association :posts is not loaded>,
  updated_at: #Ecto.DateTime<2015-10-06T17:47:07Z>, username: "test"},
 user_id: 1}
iex(6)> post.title
"Test Title"
iex(7)> post.user.username
"test"

Круто! Наш эксперимент показал ровно то, что мы ожидали, так что вернёмся обратно к контроллеру (файл web/controllers/post_controller.ex) и начнём править код. В действии index мы хотим получать все посты, связанные с пользователем. С него и начнём:

def index(conn, _params) do
  posts = Repo.all(assoc(conn.assigns[:user], :posts))
  render(conn, "index.html", posts: posts)
end

Теперь мы можем сходить посмотреть список постов для первого пользователя! Но если мы попробуем получить список постов для пользователя, которого не существует, мы получим сообщение об ошибке, что является плохим UX, так что давайте приведём в порядок наш плаг assign_user:

defp assign_user(conn, _opts) do
  case conn.params do
    %{"user_id" => user_id} ->
      case Repo.get(Pxblog.User, user_id) do
        nil  -> invalid_user(conn)
        user -> assign(conn, :user, user)
      end
    _ -> invalid_user(conn)
  end
end

defp invalid_user(conn) do
  conn
  |> put_flash(:error, "Invalid user!")
  |> redirect(to: page_path(conn, :index))
  |> halt
end

Теперь, когда мы откроем список постов для несуществующего пользователя, мы получим милое flash-сообщение и будем любезно переадресованы на page_path. Далее нам нужно изменить действие new:

def new(conn, _params) do
  changeset =
    conn.assigns[:user]
    |> build_assoc(:posts)
    |> Post.changeset()
  render(conn, "new.html", changeset: changeset)
end

Мы берём модель user, передаём её в функцию build_assoc, говоря что нам нужно создать пост, и затем передаём получившуюся пустую модель в функцию Post.changeset, чтобы получить пустую ревизию. Мы пойдём тем же путём для метода create (за исключением добавления post_params):

def create(conn, %{"post" => post_params}) do
  changeset =
    conn.assigns[:user]
    |> build_assoc(:posts)
    |> Post.changeset(post_params)
  case Repo.insert(changeset) do
    {:ok, _post} ->
      conn
      |> put_flash(:info, "Post created successfully.")
      |> redirect(to: user_post_path(conn, :index, conn.assigns[:user]))
    {:error, changeset} ->
      render(conn, "new.html", changeset: changeset)
  end
end

И затем изменим действия show, edit, update и delete:

def show(conn, %{"id" => id}) do
  post = Repo.get!(assoc(conn.assigns[:user], :posts), id)
  render(conn, "show.html", post: post)
end

def edit(conn, %{"id" => id}) do
  post = Repo.get!(assoc(conn.assigns[:user], :posts), id)
  changeset = Post.changeset(post)
  render(conn, "edit.html", post: post, changeset: changeset)
end

def update(conn, %{"id" => id, "post" => post_params}) do
  post = Repo.get!(assoc(conn.assigns[:user], :posts), id)
  changeset = Post.changeset(post, post_params)
  case Repo.update(changeset) do
    {:ok, post} ->
      conn
      |> put_flash(:info, "Post updated successfully.")
      |> redirect(to: user_post_path(conn, :show, conn.assigns[:user], post))
    {:error, changeset} ->
      render(conn, "edit.html", post: post, changeset: changeset)
  end
end

def delete(conn, %{"id" => id}) do
  post = Repo.get!(assoc(conn.assigns[:user], :posts), id)
  # Здесь мы используем delete! (с восклицательным знаком), потому что мы ожидаем
  # что оно всегда будет работать (иначе возникнет ошибка).
  Repo.delete!(post)
  conn
  |> put_flash(:info, "Post deleted successfully.")
  |> redirect(to: user_post_path(conn, :index, conn.assigns[:user]))
end

После прогона всех тестов мы должны увидеть, что всё работает. За исключением того, что… любой пользователь имеет возможность удалить/отредактировать/создать новый пост под любым юзером, каким захочет!

Ограничиваем создание постов пользователями

Мы не можем выпустить блоговый движок с такой дырой в безопасности. Давайте исправим это, добавив ещё один плаг, который гарантирует, что полученный пользователь является также текущим пользователем.

Добавим новую функцию в конец файла web/controllers/post_controller.ex:

defp authorize_user(conn, _opts) do
    user = get_session(conn, :current_user)
    if user && Integer.to_string(user.id) == conn.params["user_id"] do
      conn
    else
      conn
      |> put_flash(:error, "You are not authorized to modify that post!")
      |> redirect(to: page_path(conn, :index))
      |> halt()
    end
  end

А в самом верху добавим вызов плага:

plug :authorize_user when action in [:new, :create, :update, :edit, :delete]

Теперь всё должно прекрасно работать! Пользователи должны быть зарегистрированы, чтобы оставлять посты, а затем работать только с ними. Всё, что нам осталось — обновить набор тестов для обработки этих изменений, и всё будет готово. Для начала просто запустим mix test, чтобы оценить текущую ситуацию. Скорее всего вы увидите такую ошибку:

** (CompileError) test/controllers/post_controller_test.exs:14: function post_path/2 undefined
    (stdlib) lists.erl:1337: :lists.foreach/2
    (stdlib) erl_eval.erl:669: :erl_eval.do_apply/6
    (elixir) lib/code.ex:363: Code.require_file/2
    (elixir) lib/kernel/parallel_require.ex:50: anonymous fn/4 in Kernel.ParallelRequire.spawn_requires/5

К сожалению, нам нужно изменить каждый вызов post_path на user_post_path снова. И для того, чтобы сделать это, нам нужно радикально изменить наши тесты. Начнём с добавления блока настроек в файл test/controllers/post_controller_text.exs:

alias Pxblog.User

setup do
  {:ok, user} = create_user
  conn = build_conn()
  |> login_user(user)
  {:ok, conn: conn, user: user}
end

defp create_user do
  User.changeset(%User{}, %{email: "test@test.com", username: "test", password: "test", password_confirmation: "test"})
  |> Repo.insert
end

defp login_user(conn, user) do
  post conn, session_path(conn, :create), user: %{username: user.username, password: user.password}
end

Здесь происходит много всего. Первое, что мы сделали — добавили вызов функции create_user, которую нам нужно написать. Нам нужно несколько хелперов для тестов, так что давайте их добавим. Функция create_user просто добавляет тестового пользователя в Repo, именно поэтому мы используем сопоставление с образцом {:ok, user} при вызове этой функции.

Далее мы вызываем conn = build_conn(), также как и ранее. Далее передаём результат conn в функцию login_user. Это соединяет посты с нашей функцией входа, т. к. все основные действия с постами требуют наличие пользователя. Очень важно понять, что нам необходимо возвращать conn и таскать его с собой в каждый отдельный тест. Если мы не сделаем это, то пользователь не будет оставаться вошедшим в систему.

Наконец, мы изменили возврат той функции на возврат стандартных значений :ok и :conn, но теперь мы также включим ещё одну запись :user в словарь. Давайте взглянем на первый тест, который изменим:

test "lists all entries on index", %{conn: conn, user: user} do
  conn = get conn, user_post_path(conn, :index, user)
  assert html_response(conn, 200) =~ "Listing posts"
end

Обратите внимание, мы изменили второй аргумент метода test, чтобы при помощи сопоставления с образцом получать словарь, содержащий помимо ключа :conn, также и ключ :user. Это гарантирует, что мы используем ключ :user, с которым мы работаем в блоке setup. Помимо этого мы изменили вызов хелпера post_path на user_post_path и добавили пользователя третьим аргументом. Запустим сейчас только непосредственно этот тест. Это можно сделать с помощью указания тега, либо указав номер нужной строчки выполнив команду таким образом:

$ mix test test/controller/post_controller_test.exs:[line number]

Наш тест должен позеленеть! Великолепно! Теперь давайте изменим этот кусок:

test "renders form for new resources", %{conn: conn, user: user} do
  conn = get conn, user_post_path(conn, :new, user)
  assert html_response(conn, 200) =~ "New post"
end

Здесь ничего нового, кроме изменения обработчика setup и пути, так что идём дальше.

test "creates resource and redirects when data is valid", %{conn: conn, user: user} do
  conn = post conn, user_post_path(conn, :create, user), post: @valid_attrs
  assert redirected_to(conn) == user_post_path(conn, :index, user)
  assert Repo.get_by(assoc(user, :posts), @valid_attrs)
end

Не забывайте, что мы должны были получать каждый пост, связанный с пользователем, так что изменим все вызовы post_path.

test "does not create resource and renders errors when data is invalid", %{conn: conn, user: user} do
  conn = post conn, user_post_path(conn, :create, user), post: @invalid_attrs
  assert html_response(conn, 200) =~ "New post"
end

Другой слегка измененный тест. Смотреть нечего, так что давайте перейдём к следующему более интересному. Вспомним снова, что мы создаём/получаем посты, принадлежащие ассоциации пользователей, так что переходим к изменению теста “shows chosen resource”:

test "shows chosen resource", %{conn: conn, user: user} do
  post = build_post(user)
  conn = get conn, user_post_path(conn, :show, user, post)
  assert html_response(conn, 200) =~ "Show post"
end

Ранее мы добавляли посты с помощью простого Repo.insert! %Post{}. Это больше не будет работать, так что теперь нам нужно создавать их с правильной ассоциацией. Так как эта строчка используется довольно часто в оставшихся тестах, мы напишем хелпер, чтобы облегчить её использование.

defp build_post(user) do
  changeset =
    user
    |> build_assoc(:posts)
    |> Post.changeset(@valid_attrs)
  Repo.insert!(changeset)
end

Данный метод создаёт валидную модель поста, связанную с пользователем, и затем вставляет её в базу данных. Обратите внимание, что Repo.insert! возвращает не {:ok, model}, а возвращает саму модель!

Вернёмся к нашему тесту, который мы изменяли. Я хочу выложить остаток тестов, а вы просто повторите соответствующие изменения одно за другим, пока все тесты не начнут проходить.

test "renders page not found when id is nonexistent", %{conn: conn, user: user} do
    assert_raise Ecto.NoResultsError, fn ->
      get conn, user_post_path(conn, :show, user, -1)
    end
  end
 
 test "renders form for editing chosen resource", %{conn: conn, user: user} do
    post = build_post(user)
    conn = get conn, user_post_path(conn, :edit, user, post)
    assert html_response(conn, 200) =~ "Edit post"
  end

  test "updates chosen resource and redirects when data is valid", %{conn: conn, user: user} do
    post = build_post(user)
    conn = put conn, user_post_path(conn, :update, user, post), post: @valid_attrs
    assert redirected_to(conn) == user_post_path(conn, :show, user, post)
    assert Repo.get_by(Post, @valid_attrs)
  end

  test "does not update chosen resource and renders errors when data is invalid", %{conn: conn, user: user} do
    post = build_post(user)
    conn = put conn, user_post_path(conn, :update, user, post), post: %{"body" => nil}
    assert html_response(conn, 200) =~ "Edit post"
  end

  test "deletes chosen resource", %{conn: conn, user: user} do
    post = build_post(user)
    conn = delete conn, user_post_path(conn, :delete, user, post)
    assert redirected_to(conn) == user_post_path(conn, :index, user)
    refute Repo.get(Post, post.id)
  end

Когда вы поправите их все, то сможете запустить команду mix test и получить зелёные тесты!

Наконец, мы написали немного нового кода, такого как плаги для обработки поиска пользователей и авторизации, и мы протестиовали успешные случаи довольно хорошо, но нам нужно добавить тесты и на негативные случаи. Мы начнём с теста на то, что произойдёт, когда мы попробуем получить доступ к постам пользователя, который не существует.

test "redirects when the specified user does not exist", %{conn: conn} do
  conn = get conn, user_post_path(conn, :index, -1)
  assert get_flash(conn, :error) == "Invalid user!"
  assert redirected_to(conn) == page_path(conn, :index)
  assert conn.halted
end

Мы не включили :user в сопоставление с образцом из блока setup, т. к. здесь его не используем. Также проверяем, что соединение закрывается в конце.

И наконец, нам нужно написать тест, в котором мы попробуем отредактировать чужой пост.

test "redirects when trying to edit a post for a different user", %{conn: conn, user: user} do
  other_user = User.changeset(%User{}, %{email: "test2@test.com", username: "test2", password: "test", password_confirmation: "test"})
  |> Repo.insert!
  post = build_post(user)
  conn = get conn, user_post_path(conn, :edit, other_user, post)
  assert get_flash(conn, :error) == "You are not authorized to modify that post!"
  assert redirected_to(conn) == page_path(conn, :index)
  assert conn.halted
end

Мы создаём другого пользователя, который станет нашим плохим пользователем, и добавляем его в Repo. Затем мы пробуем получить доступ к действию edit для поста нашего первого пользователя. Это заставит сработать негативный случай нашего плага authorize_user! Сохраните файл, запустите команду mix test и дождитесь результатов:

.......................................
Finished in 0.4 seconds
39 tests, 0 failures
Randomized with seed 102543

Вот так-то! Проделали немало! Зато теперь у нас есть функциональный (и более защищённый блог) с постами, создающимися под пользователями. И у нас по-прежнему хорошее покрытие тестами! Пришло время передохнуть. Мы продолжим эту серию обучающих материалов добавлением роли администратора, комментариев, поддержки Markdown, и наконец ворвёмся в каналы с живой системой комментирования!

Важное заключение от переводчика

Мною была проделана огромная работа по переводу как этой статьи, так и переводу всей серии. Чем я продолжаю заниматься и сейчас. Поэтому, если вам понравилась сама статья или начинания в популяризации Эликсира в рунете, пожалуйста, поддержите статью плюсами, комментариями и репостами. Это невероятно важно как для меня лично, так и для всего сообщества Эликсира в целом.

Другие статьи серии

1. Вступление
2. Авторизация
3. Добавляем роли
4. Обрабатываем роли в контроллерах
5. Подключаем ExMachina
6. Поддержка Markdown
7. Добавляем комментарии
8. Заканчиваем с комментариями
9. Каналы
10. Тестирование каналов
11. Заключение

Обо всех неточностях, ошибках, плохом переводе, пожалуйста, пишите личными сообщениями, буду оперативно исправлять. Заранее благодарю всех участвующих.