Writing a Blog Engine in Phoenix and Elixir: Part 1

: 07/20/2016 Last Updated At Current Versions: As of the time of writing this, the current versions of our applications are: : v1.3.1 Elixir v1.2.0 Phoenix: v2.0.2 Ecto: v2.5.2 Comeonin: If you are reading this and these are not the latest, let me know and I’ll update this tutorial accordingly. Installing Phoenix The best instructions for installing Phoenix can be found on the Phoenix website. Step 1: Let’s Add Posts We need to start by using the Phoenix mix task to create a new project, which we will call “pxblog”. We do this using the mix phoenix.new [project] [command]. Answer Y to all questions, since we do want to use phoenix.js and the other front-end requirements. mix phoenix.new pxblog Output: * creating pxblog/config/config.exs... Fetch and install dependencies? [Yn] y* running mix deps.get* running npm install && node node_modules/brunch/bin/brunch build We are all set! Run your Phoenix application: $ cd pxblog$ mix phoenix.server You can also run your app inside IEx (Interactive Elixir) as: $ iex -S mix phoenix.server Before moving on, configure your database in config/dev.exs and run: $ mix ecto.create We should see a bunch of output indicating that our project has been completed and the initial work is done. The step may fail if we have not set up our postgres database correctly or configured our application to use the right credentials. If you open up , you should see some configuration details at the bottom of the file: mix ecto.create config/dev.exs # Configure your databaseconfig :pxblog, Pxblog.Repo,adapter: Ecto.Adapters.Postgres,username: "postgres",password: "postgres",database: "pxblog_dev",hostname: "localhost",pool_size: 10 Just change the username and password to a role that has the correct database creation permissions. When we have that working, we’ll start up the server just to make sure everything is fine. $ iex -S mix phoenix.server We should now be able to visit and see the “Welcome to Phoenix!” page. Now that we have a good baseline, let’s add our basic scaffold for creating posts, since this is after all a blogging engine. http://localhost:4000/ The first thing we’ll do is utilize one of Phoenix’s generators to build us not only the Ecto model and migration, but the UI scaffolding to handle the CRUD ( ) operations for our Post object. Since this is a very, very simple blog engine right now, let’s just stick with a title and a body; the title will be a string and the body will be text. The syntax for these generators is pretty straightforward: Create, Read, Update, Delete mix phoenix.gen.html [Model Name] [Table Name] [Column Name:Column Type]… $ mix phoenix.gen.html Post posts title:string body:text Output: * creating web/controllers/post_controller.ex... Add the resource to your browser scope in web/router.ex: resources "/posts", PostController Remember to update your repository by running migrations: $ mix ecto.migrate Next, to make this scaffold accessible (and stop Elixir from complaining), we’re going to open up web/router.ex, and add the following to our root scope (the “/” scope, using the pipeline): :browser resources "/posts", PostController Finally, we’re going to make sure that our database has this new migration loaded by calling . mix ecto.migrate Output: Compiling 9 files (.ex)Generated pxblog app 15:52:20.004 [info] == Running Pxblog.Repo.Migrations.CreatePost.change/0 forward 15:52:20.004 [info] create table posts 15:52:20.019 [info] == Migrated in 0.0s Finally, let’s restart our server, and then visit and we should see the “Listing posts” header with a table containing the columns in our object. http://localhost:4000/posts Mess around a bit and you should be able to create new posts, edit posts, and delete posts. Pretty cool for very little work! Step 1B: Writings Tests for Posts The beautiful thing of working with the scaffolds at the start is that it will create the baseline tests for us from the start. We don’t even really need to modify much yet since we haven’t really changed any of the scaffolds, but let’s analyze what was created for us so that we can be better prepared to write our own tests later. First, we’ll open up and take a look: test/models/post_test.exs defmodule Pxblog.PostTest douse Pxblog.ModelCase alias Pxblog.Post @valid_attrs %{body: "some content", title: "some content"}@invalid_attrs %{} test "changeset with valid attributes" dochangeset = Post.changeset(%Post{}, @valid_attrs)assert changeset.valid?end test "changeset with invalid attributes" dochangeset = Post.changeset(%Post{}, @invalid_attrs)refute changeset.valid?endend Let’s take this apart and understand what’s going on. defmodule Pxblog.PostTest do Clearly, we need to define our Test module using our application’s namespace. use Pxblog.ModelCase Next, we tell this module that it is going to be using the functions and DSL introduced by the ModelCase macro set. alias Pxblog.Post Now make sure that the test has visibility into the model itself. @valid_attrs %{body: “some content”, title: “some content”} Set up some basic valid attributes that would be able to create a successful changeset. This just provides a module-level variable that we can pull from every time we want to be able to create a valid model. @invalid_attrs %{} Like the above, but creating, unsurprisingly, an invalid attribute set. test "changeset with valid attributes" dochangeset = Post.changeset(%Post{}, @valid_attrs)assert changeset.valid?end Now, we create our test by giving it a string-based name using the “test” function. Inside of our function body, we first create a changeset from the Post model (given it a blank struct and the list of valid parameters). We then assert that the changeset is valid, since that is what we’re expecting with the @valid_attrs variable. test "changeset with invalid attributes" dochangeset = Post.changeset(%Post{}, @invalid_attrs)refute changeset.valid?end Finally, we check against creating a changeset with an invalid parameter list, and instead of asserting the changeset is valid, we perform the reverse operation. refute is essentially assert not true. This is a pretty good example of how to write a model test file. Now let’s take a look at the controller tests. Let’s take a look at the top, since that all looks roughly the same: defmodule Pxblog.PostControllerTest douse Pxblog.ConnCase alias Pxblog.Post@valid_attrs %{body: "some content", title: "some content"}@invalid_attrs %{} The first change set can see is Pxblog.ConnCase; we’re relying on the DSL that is exposed for controller-level tests. Other than that, the rest of the lines should be pretty familiar. Let’s take a look at the first test: test "lists all entries on index", %{conn: conn} doconn = get conn, post_path(conn, :index)assert html_response(conn, 200) =~ "Listing posts"end Here, we grab the “conn” variable that is going to be sent via a setup block in ConnCase. I’ll explain this later. The next step is for us to call the appropriate verb to hit the expected route, which in our case is a get request against our index action. We then assert that the response of this action returns HTML with a status of 200 (“ok”) and contains the phrase “Listing posts.” test "renders form for new resources", %{conn: conn} doconn = get conn, post_path(conn, :new)assert html_response(conn, 200) =~ "New post"end The next test is basically the same, but we’re just validating the “new” action instead. Simple stuff. test "creates resource and redirects when data is valid", %{conn: conn} doconn = post conn, post_path(conn, :create), post: @valid_attrsassert redirected_to(conn) == post_path(conn, :index)assert Repo.get_by(Post, @valid_attrs)end Now, we’re doing something new. First, this time we’re posting to the helper with our list of valid parameters. We’re expecting to get redirected to the index route for the post resource. takes in a connection object as an argument, since we need to see where that connection object was redirected to. post_path redirected_to Finally, we assert that the object represented by those valid parameters are inserted into the database successfully through querying our Ecto Repo, looking for a Post model that matches our @valid_attrs parameters. Now, we want to test the negative path for creating a new Post. test "does not create resource and renders errors when data is invalid", %{conn: conn} doconn = post conn, post_path(conn, :create), post: @invalid_attrsassert html_response(conn, 200) =~ "New post"end So, we post to the same create path but with our invalid_attrs parameter list, and we assert that it renders out the New Post form again. test "shows chosen resource", %{conn: conn} dopost = Repo.insert! %Post{}conn = get conn, post_path(conn, :show, post)assert html_response(conn, 200) =~ "Show post"end To test our show action, we make sure that we create a Post model to work with. We then call our get function to the post_path helper, and we make sure it returns the appropriate resource. However, if we attempt to grab a show path to a resource that does not exist, we do the following: test "renders page not found when id is nonexistent", %{conn: conn} doassert_error_sent 404, fn ->get conn, post_path(conn, :show, -1)endend We see a new pattern here, but one that is actually pretty simple to digest. We expect that if we fetch a resource that does not exist, that we should receive a 404. We then pass it an anonymous function which contains the code we want to execute that should return that error. Simple! The rest of the tests are just repeats of the above for each path, with the exception of our delete action. Let’s take a look: test "deletes chosen resource", %{conn: conn} dopost = Repo.insert! %Post{}conn = delete conn, post_path(conn, :delete, post)assert redirected_to(conn) == post_path(conn, :index)refute Repo.get(Post, post.id)end Here, most of what we see is the same, with the exception of using our delete verb. We assert that we redirect out of the delete page back to the index, but we do something new here: we refute that the Post object exists anymore. Assert and Refute are truthy, so the existence of an object at all will work with an Assert and cause a Refute to fail. We didn’t add any code to our view, so we don’t do anything with our PostView module. Step 2: Adding Users We’re going to follow almost the exact same steps we followed with creating our Post object to create our User object, except with a few different columns. First, we’ll run: $ mix phoenix.gen.html User users username:string email:string password_digest:string Output: * creating web/controllers/user_controller.ex... Add the resource to your browser scope in web/router.ex: resources "/users", UserController Remember to update your repository by running migrations: $ mix ecto.migrate Next, we’ll open up web/router.ex, and add the following to our browser scope again: resources "/users", UserController The syntax here is defining a standard resourceful route where the first argument is the URL and the second is the controller’s class name. We’ll then run mix ecto.migrate Output: Compiling 11 files (.ex)Generated pxblog app 16:02:03.987 [info] == Running Pxblog.Repo.Migrations.CreateUser.change/0 forward 16:02:03.987 [info] create table users 16:02:03.996 [info] == Migrated in 0.0s And finally, restart the server and check out We can now independently create Posts and Users! Unfortunately, this isn’t a very useful blog yet. After all, we can create users (anyone can, in fact), but we can’t even log in. Plus, password digests aren’t coming from any encryption algorithm; the user is just creating them and we’re storing them in plain text! No bueno! http://localhost:4000/users. We’ll make this look more like a real user registration screen instead. Our tests for the user stuff looks exactly the same as what was auto-generated for our Posts, so we’ll leave those alone until we start modifying the logic (IE, right now!) Step 3: Saving a Password Hash instead of a Password When we visit , we see three fields: , , and . But when you register on other sites, you would enter a password and a password confirmation! How can we correct this? /users/new Username Email PasswordDigest In , delete the following lines: web/templates/user/form.html.eex And add in its place: Refresh the page (should happen automatically), enter user details, hit submit. Error: Oops, something went wrong! Please check the errors below. This is because we’re creating a password and password confirmation but nothing is being done to create the actual password_digest. Let’s write some code to do this. First, we’re going to modify the actual schema to do something new: In : web/models/user.ex schema "users" dofield :username, :stringfield :email, :stringfield :password_digest, :string timestamps Virtual Fields field :password, :string, virtual: truefield :password_confirmation, :string, virtual: trueend Note the addition of the two fields, :password and :password_confirmation. We’re declaring these as fields, as these do not actually exist in our database but need to exist as properties in our User struct. This also allows us to apply transformations in our changeset function. virtual We then modify the list of required fields and casted fields to include : and : . password password_confirmation def changeset(struct, params \\ %{}) dostruct|> cast(params, [:username, :email, :password, :password_confirmation])|> validate_required([:username, :email, :password, :password_confirmation])end If you run at this point, you’ll notice that our “changeset with valid attributes” test is now failing. That’s because we made password and password_confirmation required but did not update our @valid_attrs map to include either. Let’s change that line to: test/models/user_test.exs @valid_attrs %{email: " ", password: "test1234", password_confirmation: "test1234", username: "testuser"} test@test.com Our model tests should be right back to passing! We also need our controller tests passing. In , we’ll make some modifications. First, we’ll distinguish between valid creation attributes and valid searching attributes: test/controllers/user_controller_test.exs @valid_create_attrs %{email: " ", password: "test1234", password_confirmation: "test1234", username: "testuser"}@valid_attrs %{email: " ", username: "testuser"} test@test.com test@test.com Then we’ll modify our creation test: test "creates resource and redirects when data is valid", %{conn: conn} doconn = post conn, user_path(conn, :create), user: @valid_create_attrsassert redirected_to(conn) == user_path(conn, :index)assert Repo.get_by(User, @valid_attrs)end And our update test: test "updates chosen resource and redirects when data is valid", %{conn: conn} douser = Repo.insert! %User{}conn = put conn, user_path(conn, :update, user), user: @valid_create_attrsassert redirected_to(conn) == user_path(conn, :show, user)assert Repo.get_by(User, @valid_attrs)end With our tests back to green, we need to modify the changeset function to change our password into a password digest on the fly: def changeset(struct, params \\ %{}) dostruct|> cast(params, [:username, :email, :password, :password_confirmation])|> validate_required([:username, :email, :password, :password_confirmation])|> hash_passwordend defp hash_password(changeset) dochangeset|> put_change(:password_digest, "ABCDE")end Right now we’re just stubbing out the behavior of our hashing function. The first step is to make sure that we can modify our changeset as we go along. Let’s verify this behavior first. Go back to in our browser, click on “New user”, and create a new user with any details. When we hit the index page again, we should expect to see the user created with a password_digest value of “ABCDE”. http://localhost:4000/users And run our tests again for this file. Our tests are passing, but we haven’t added any tests for this new work. Let’s add a test in our suite of model tests that will add a test on password digest: hash_password test "password_digest value gets set to a hash" dochangeset = User.changeset(%User{}, @valid_attrs)assert get_change(changeset, :password_digest) == "ABCDE"end This is a great step forward, but not terribly great for security! Let’s modify our hashes to be real password hashes with Bcrypt, courtesy of the library. comeonin First, open up and add to our list of applications: mix.exs :comeonin def application do[mod: {Pxblog, []},applications: [:phoenix, :phoenix_pubsub, :phoenix_html, :cowboy, :logger, :gettext,:phoenix_ecto, :postgrex, :comeonin]]end And we’ll also need to modify our deps definition: defp deps do[{:phoenix, "~> 1.2.0"},{:phoenix_pubsub, "~> 1.0"},{:phoenix_ecto, "~> 3.0"},{:postgrex, ">= 0.0.0"},{:phoenix_html, "~> 2.6"},{:phoenix_live_reload, "~> 1.0", only: :dev},{:gettext, "~> 0.11"},{:cowboy, "~> 1.0"},{:comeonin, "~> 2.3"}]end Same here, note the addition of . Now, let’s shut down the server we’ve been running and run . If all goes well (it should!), then now you should be able to rerun to restart your server. {:comeonin, “~> 2.3”} mix deps.get iex -S mix phoenix.server Our old method is neat, but we need it to actually hash our password. Since we’ve added the library, which provides us a nice Bcrypt module with a hashpwsalt method, so let’s import that into our User model. hash_password comeonin In , add the following line to the top just under our line: web/models/user.ex use Pxblog.Web, :model import Comeonin.Bcrypt, only: [hashpwsalt: 1] What we’re doing here is pulling in the Bcrypt module under the Comeonin namespace and importing the hashpwsalt method with an arity of 1. And now we’re going to modify our method to work. hash_password defp hash_password(changeset) doif password = get_change(changeset, :password) dochangeset|> put_change(:password_digest, hashpwsalt(password))elsechangesetendend Let’s try creating a user again! This time, after entering in our data for username, email, password, and password confirmation, we should see an encrypted digest show up in the field! password_digest Now, we’re going to want to work on the function that we added. The first thing we’re going to want to do is change the configuration for our testing environment to make sure our tests don’t slow down dramatically when working with our password encryption. Open up and add the following to the bottom: hash_password config/test.exs config :comeonin, bcrypt_log_rounds: 4 This will configure ComeOnIn when it’s in our test environment to not try too hard to encrypt our password. Since this is only for tests, we don’t need anything super secure and would prefer sanity and speed instead! In , we’ll want to instead change that to: config/prod.exs config :comeonin, bcrypt_log_rounds: 14 Let’s write a test for the comeonin call. We’ll make it a little less specific; we just want to verify the encryption. In : test/models/user_test.exs test "password_digest value gets set to a hash" dochangeset = User.changeset(%User{}, @valid_attrs)assert Comeonin.Bcrypt.checkpw(@valid_attrs.password, Ecto.Changeset.get_change(changeset, :password_digest))end For some more test coverage, let’s add a case to handle if the password = get_change() line is not hit: test "password_digest value does not get set if password is nil" dochangeset = User.changeset(%User{}, %{email: "test@test.com", password: nil, password_confirmation: nil, username: "test"})refute Ecto.Changeset.get_change(changeset, :password_digest)end Since assert/refute use truthiness, we can see if this block of code leaves blank, which it does! We’re doing a good job of covering our work with specs! password_digest Step 4: Let’s log in! Let’s add a new controller, SessionController and an accompanying view, SessionView. We’ll start simple and build our way up to a better implementation over time. Create web/controllers/session_controller.ex: defmodule Pxblog.SessionController douse Pxblog.Web, :controller def new(conn, _params) dorender conn, "new.html"endend Create : web/views/session_view.ex defmodule Pxblog.SessionView douse Pxblog.Web, :viewend Create : web/templates/session/new.html.eex Login And finally, let’s update the router to include this new controller. Add the following line to our “/” scope: resources "/sessions", SessionController, only: [:new] The only route that we want to expose for the time being is , so we’re going to limit it just to that. Again, we want to keep things simple and build up from a stable foundation. new Now let’s visit and we should expect to see the Phoenix framework header and the “Login” header. http://localhost:4000/sessions/new Let’s give it a real form. Create : web/templates/session/form.html.eex %> Oops, something went wrong! Please check the errors below:

Username Password And modify to call our new form by adding one line: web/templates/session/new.html.eex The autoreloading will end up displaying an error page right now because we haven’t actually defined , which as you may guess needs to be a changeset. Since we’re working with the member object, which has username and password fields already on it, let’s use that! @changeset In , we need to alias the User model to be able to use it further. At the top of our class, under our line, add the following: web/controllers/session_controller.ex use Pxblog.Web, :controller alias Pxblog.User And in the function, modify the call to render as follows: new render conn, "new.html", changeset: User.changeset(%User{}) We need to pass it the connection, the template we’re rendering (minus the eex), and a list of additional variables that should be exposed to our templates. In this case, we want to expose @changeset, so we specify changeset: here, and we give it the Ecto changeset for the User with a blank User struct. (%User{} is a User Struct with no values set) Refresh now and we get a different error message that should resemble the following: No helper clause for Pxblog.Router.Helpers.session_path/2 defined for action :create.The following session_path actions are defined under your router:*:new In our form, we are referencing a route that doesn’t actually exist yet! We are using the session_path helper, passing it the @conn object, but then specifying the :create path which we’ve not created yet. We’ve gotten part of the way there. Now let’s make it so we can actually post our login details and set the session. Let’s update our routes to allow posting to create. In , change our reference to SessionController to also include :create. web/router.ex resources "/sessions", SessionController, only: [:new, :create] In , we need to import a new function, checkpw from Comeonin’s Bcrypt module. We do this via the following line: web/controllers/session_controller.ex import Comeonin.Bcrypt, only: [checkpw: 2] This line is saying “Import from the Comeonin.Bcrypt module, but only the checkpw function with an arity of 2”. And then let’s add a scrub_params plug to deal with User data. Before our functions, we’ll add: plug :scrub_params, "user" when action in [:create] “scrub_params” is a special function that cleans up any user input; in the case where something is passed in as a blank string, for example, scrub_params will convert it into a nil value instead to avoid creating entries in your database that have empty strings. And let’s add our function to handle the create post. We’re going to add this to the bottom of our SessionController module. There’s going to be a lot of code here, so we’ll take it piece by piece. In : web/controllers/session_controller.ex def create(conn, %{"user" => user_params}) doRepo.get_by(User, username: user_params["username"])|> sign_in(user_params["password"], conn)end The first bit of this code, pulls the first applicable User from our Ecto Repo that has a matching username, or will otherwise return nil. Repo.get_by(User, username: user_params[“username”]) Here is some output to verify this behavior: iex(3)> Repo.get_by(User, username: "flibbity")[debug] SELECT u0."id", u0."username", u0."email", u0."password_digest", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."username" = $1) ["flibbity"] OK query=0.7msnil iex(4)> Repo.get_by(User, username: "test")[debug] SELECT u0."id", u0."username", u0."email", u0."password_digest", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."username" = $1) ["test"] OK query=0.8ms%Pxblog.User{__meta__: %Ecto.Schema.Metadata{source: "users", state: :loaded},email: "test", id: 15,inserted_at: %Ecto.DateTime{day: 24, hour: 19, min: 6, month: 6, sec: 14,usec: 0, year: 2015}, password: nil, password_confirmation: nil,password_digest: "$2b$12$RRkTZiUoPVuIHMCJd7yZUOnAptSFyM9Hw3Aa88ik4erEsXTZQmwu2",updated_at: %Ecto.DateTime{day: 24, hour: 19, min: 6, month: 6, sec: 14,usec: 0, year: 2015}, username: "test"} We then take the user, and chain that user into a sign_in method. We haven’t written that yet, so let’s do so! defp sign_in(user, password, conn) when is_nil(user) doconn|> put_flash(:error, "Invalid username/password combination!")|> redirect(to: page_path(conn, :index))end defp sign_in(user, password, conn) doif checkpw(password, user.password_digest) doconn|> put_session(:current_user, %{id: user.id, username: user.username})|> put_flash(:info, "Sign in successful!")|> redirect(to: page_path(conn, :index))elseconn|> put_session(:current_user, nil)|> put_flash(:error, "Invalid username/password combination!")|> redirect(to: page_path(conn, :index))endend The first thing to notice is the order that these methods are defined in. The first of these methods has a guard clause attached to it, so that method will only be executed when that guard clause is true, so if the user is nil, we redirect back to the index of the page (root) path with an appropriate flash message. The second method will get called if the guard clause is false and will handle all other scenarios. We check the result of that checkpw function, and if it is true, we set the user to the current_user session variable and redirect with a success message. Otherwise, we clear out the current user session, set an error message, and redirect back to the root. If we return to our login page http://localhost:4000/sessions/new, we should be able to test out login with a valid set of credentials and invalid credentials and see the appropriate error messages! We need to write some specs for this controller, as well. We’ll create and fill it with the following: test/controllers/session_controller_test.exs defmodule Pxblog.SessionControllerTest douse Pxblog.ConnCasealias Pxblog.User setup doUser.changeset(%User{}, %{username: "test", password: "test", password_confirmation: "test", email: " "})|> Repo.insert{:ok, conn: build_conn()}end test@test.com test "shows the login form", %{conn: conn} doconn = get conn, session_path(conn, :new)assert html_response(conn, 200) =~ "Login"end test "creates a new user session for a valid user", %{conn: conn} doconn = post conn, session_path(conn, :create), user: %{username: "test", password: "test"}assert get_session(conn, :current_user)assert get_flash(conn, :info) == "Sign in successful!"assert redirected_to(conn) == page_path(conn, :index)end test "does not create a session with a bad login", %{conn: conn} doconn = post conn, session_path(conn, :create), user: %{username: "test", password: "wrong"}refute get_session(conn, :current_user)assert get_flash(conn, :error) == "Invalid username/password combination!"assert redirected_to(conn) == page_path(conn, :index)end test "does not create a session if user does not exist", %{conn: conn} doconn = post conn, session_path(conn, :create), user: %{username: "foo", password: "wrong"}assert get_flash(conn, :error) == "Invalid username/password combination!"assert redirected_to(conn) == page_path(conn, :index)endend We start off with our standard setup block, and write a pretty standard assertion for a get request. The creation bits are where this starts to get more interesting: test "creates a new user session for a valid user", %{conn: conn} doconn = post conn, session_path(conn, :create), user: %{username: "test", password: "test"}assert get_session(conn, :current_user)assert get_flash(conn, :info) == "Sign in successful!"assert redirected_to(conn) == page_path(conn, :index)end The first bit here is posting to our session creation path. We then verify that we set the current_user session variable, the flash message for the action, and finally, we assert where we are being redirected to. The other two calls are just using the same sort of assertions (and in one case, a refutation) to make sure we’re testing all of the paths that the sign_in function can hit. Again, very simple stuff! Step 5: Exposing our current_user Let’s modify our layout to display a message or a link depending on if the member is logged in or not. In , let’s write a helper that will make it easy for us to access the user information, so we’ll add: web/views/layout_view.ex def current_user(conn) doPlug.Conn.get_session(conn, :current_user)end Let’s write a test to make sure this works. In , instead of the “Get Started” link, let’s do the following: web/templates/layout/app.html.eex Logged in as Again, let’s step through this piece by piece. One of the first things we need to do is figure out who the current user is, assuming they’re logged in. We’re going with a simple first, refactor later approach, so for right now we’re going to just set a user object from the session right in our template. get_session is part of the Plug.Conn object. If the user exists (this takes advantage of Elixir’s Ruby-like truthiness values in that nil will return false here.) If the user is logged in, we’ll also want to provide a link as well. Even though this does not exist yet, it will eventually need to exist, so for right now we’re going to send it along. We’ll treat a session like a resource, so to logout, we’ll “delete” the session, so we’ll provide a link to it here. logout We also want to output the current user’s username. We’re storing the user struct in the :current_user session variable, so we can just access the username as user.username. If we could not find the user, then we’ll just provide the login link. Again, we’re treating sessions like a resource here, so “new” will provide the appropriate route to create a new session. You probably noticed that when everything refreshed, we’re getting another error message about a missing matching function clause. Let’s add our delete route as well to keep Phoenix happy! In , we’ll modify our “sessions” route to also allow :delete: web/router.ex resources "/sessions", SessionController, only: [:new, :create, :delete] And let’s modify the controller as well. In , add the following: web/controllers/session_controller.ex def delete(conn, _params) doconn|> delete_session(:current_user)|> put_flash(:info, "Signed out successfully!")|> redirect(to: page_path(conn, :index))end Since we’re just deleting the :current_user key, we don’t actually care what the params are, so we mark those as unused with an underscore. We set a flash message to make the UI a little more clear to the user and redirect back to our root route. We can now log in, log out, and see login failures too! Things are shaping up for the best! But first, we need to write some tests. We’ll start with the tests for our LayoutView. defmodule Pxblog.LayoutViewTest douse Pxblog.ConnCase, async: true alias Pxblog.LayoutViewalias Pxblog.User setup doUser.changeset(%User{}, %{username: "test", password: "test", password_confirmation: "test", email: " "})|> Repo.insert{:ok, conn: build_conn()}end test@test.com test "current user returns the user in the session", %{conn: conn} doconn = post conn, session_path(conn, :create), user: %{username: "test", password: "test"}assert LayoutView.current_user(conn)end test "current user returns nothing if there is no user in the session", %{conn: conn} douser = Repo.get_by(User, %{username: "test"})conn = delete conn, session_path(conn, :delete, user)refute LayoutView.current_user(conn)endend Let’s analyze. The first thing we’re going to do is alias the LayoutView and User modules so that we can shorten some of our code. Next, in our setup block, we create a User and throw it into the database. We then return our standard tuple. {:ok, conn: build_conn()} We then write our first test by logging in to our session create action and asserting that, after logging in, the LayoutView.current_user function returns some data. We then write for our negative case; we explicitly delete the session and refute that a user is returned out of our current_user call. We also updated our SessionController by adding a delete action, so we need to get our tests all set. test "deletes the user session", %{conn: conn} douser = Repo.get_by(User, %{username: "test"})conn = delete conn, session_path(conn, :delete, user)refute get_session(conn, :current_user)assert get_flash(conn, :info) == "Signed out successfully!"assert redirected_to(conn) == page_path(conn, :index)end We make sure that current_user from the session is blank, then we check the flash message and make sure we get redirected out! Possible errors with compiling assets One thing to note is that you may end up hitting an error when you’re trying to compile the assets with brunch. The error message I got was: 16 Dec 23:30:20 — error: Compiling of ‘web/static/js/app.js’ failed. Couldn’t find preset “es2015” relative to directory “web/static/js” ; Compiling of ‘web/static/js/socket.js’ failed. Couldn’t find preset “es2015” relative to directory “web/static/js” ; Compiling of ‘deps/phoenix/web/static/js/phoenix.js’ failed. Couldn’t find preset “es2015” relative to directory “deps/phoenix/web/static/js” ; Compiling of ‘deps/phoenix_html/web/static/js/phoenix_html.js’ failed. Couldn’t find preset “es2015” relative to directory “deps/phoenix_html/web/static/js” You can fix this with installing with NPM. I ran the following command: babel-preset-es2015 npm install -g babel-preset-es2015 Now if you start up the server you should see all of the assets correctly compiled in! Next post in this series _Last Updated At: 07/21/2016_medium.com Writing a Blog Engine in Phoenix and Elixir: Part 2, Authorization Check out my new book! Hey everyone! If you liked what you read here and want to learn more with me, check out my new book on Elixir and Phoenix web development: _Learn to build a high-performance functional prototype of a voting web application from scratch using Elixir and…_www.packtpub.com Phoenix Web Development | PACKT Books I’m really excited to finally be bringing this project to the world! It’s written in the same style as my other tutorials where we will be building the scaffold of a full project from start to finish, even covering some of the trickier topics like file uploads, Twitter/Google OAuth logins, and APIs! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories