Veil - Simple Passwordless Authentication for your Phoenix Apps

Your Libraries & OS Mentoring Libraries
,
1

Veil - Simple Passwordless Authentication for your Phoenix Apps

I have just released the first version of Veil, a very simple library to add passwordless authentication to your Phoenix apps. Starting from a new project, you can have authentication working in five minutes (and most of that time is getting an API key from your email api of choice).

I have noticed a lot of people asking about the best solution for adding authentication to new projects and I think this provides that. It has far less functionality than Guardian or Coherence, but in turn is faster to set up if you don’t need all the bells and whistles that they offer.

I don’t think most websites need to use the username/password paradigm, and authenticating by email automatically verifies all of your emails on signup. You have full control over the expiry of session tokens and can easily revoke them on the server if you want.

All the schemas/controllers/plugs/templates are added directly to your Phoenix project so you can easily customise/extend them as much as you wish.

Would really appreciate any feedback!

13 Likes
2

Would be nice to add a little more detail to the post on the forum. Could you show a quick snippet of use? Also will this work with any email provider?

3

Thanks for the library!

But how is it better than using bamboo and a single controller? That’s how I do authentication over email right now. I guess what I’m asking is, if I already have passwordless authentication set up, should I switch to your library?

1 Like
4

Sure! Veil adds a new mix task that you run with mix veil.add. This then does the following:

  • Adds schemas for Veil.User, Veil.Request, Veil.Session
  • Adds User & Session controllers & views
  • Adds a mailer
  • Adds three Plugs
  • Adds HTML templates (if your phoenix app has a templates directory)
  • Amends your config file to add the Veil-specific settings
  • Amends the default layout.html.eex to add a sign in link
  • Amends your router to add one of the Plugs to the default pipeline, and adds two new blocks: one for Veil’s sign in/session routes, and one that only signed in users can access.

It also includes code to generate unguessable unique secure ids for requests and sessions, and this code isn’t copied to your app (since it doesn’t need modifying).

In practical terms, this gives you:

  • A sign in/signup form (email address only) that sends an email to the address given
  • Clicking the link in that email will sign the user into the application and set a session id in a cookie
  • You can then add protected routes in the new router block that will only be accessible to logged in users

Regarding email providers, it uses Swoosh by default, which includes the following adaptors for different services: Sendgrid, Mandrill, Mailgun, Postmark, SparkPost, and SMTP.

Please let me know if you have any further questions.

6 Likes
5

Good question. Honestly, if you have already set up your own authentication by email, then it probably makes sense to continue using that. This isn’t a terribly hard problem, so if you’ve already done the work it’s unlikely that you want to switch.

That said, it may have a few advantages over your solution (guessing of course):

  • Secure request/session ids that can easily be invalidated server-side.
  • Login requests are also stored in the database, so it is easy to see failed login attempts (although these are deleted by a task daily, it would be easy to add another task to email a list of users with multiple failed attempts to the website admin daily).

I think the main advantage comes if you are starting a new project - you can be set up in 5 minutes without needing to roll your own method.

If you have a few minutes free, maybe try creating a new project with Veil included and see if it works significantly differently. If your method is better in any way I’d love improvement suggestions!

5 Likes
7

If you’re curious how Veil works, I made an screencast where I use it with an existing Phoenix application: https://elixircasts.io/passwordless-authentication-with-veil

9 Likes
8

Just watched the ElixirCast and was up and running with Veil in under 10 minutes! Really fantastic on-boarding experience, wish that other auth solutions shared Veil’s ease-of-use…

Has anyone “outgrown” Veil and incorporated other authentication solutions such as OAuth? Curious how much pain there will be down the line if I decide to build a more fully featured authentication suite for my app…

2 Likes
9

What if I have an existing User schema? Will VeilUser integrate seamlessly? OR if I’m starting from scratch and use a VeilUser as my principal user module, how do I extend its functionality for my “problem domain”?

10

Hi,

My question may seem stupid… but I really need an answer. I’m trying to get Veil working on my fresh created phoenix app… and when I do mix deps.get I get this error:

Failed to use “ecto” (versions 3.0.0 and 3.0.1) because
crontab (versions 1.1.0 to 1.1.4) requires ~> 1.0 or ~> 2.0 or ~> 2.1
ecto_sql (version 3.0.0) requires ~> 3.0.0
phoenix_ecto (version 4.0.0) requires ~> 3.0

Yes, I’m new to Elixir, and Phoenix also. I’m desperate because I’ve tried mix deps.unlock --all and also mix deps.clean --all … but it doesn’t work. My mix.ex deps look like this:

defp deps do
[
{:phoenix, “~> 1.4.0”},
{:phoenix_pubsub, “~> 1.1”},
{:phoenix_ecto, “~> 4.0”},
{:ecto_sql, “~> 3.0”},
{:postgrex, “>= 0.0.0”},
{:phoenix_html, “~> 2.11”},
{:phoenix_live_reload, “~> 1.2”, only: :dev},
{:gettext, “~> 0.11”},
{:jason, “~> 1.0”},
{:plug_cowboy, “~> 2.0”},
{:veil, “~> 0.2”}
]
end

What should I change? How can I make it install and work?

11

:wave:

Maybe you can downgrade to a previous version of phoenix? The one which worked with ecto ~> 2.0, at least until :crontab gets updated.

Your deps would look something like

defp deps do
  [
    {:phoenix, “~> 1.3.0”}, # note the change
    {:phoenix_pubsub, “~> 1.1”},
    {:phoenix_ecto, “~> 3.0”}, # note the change
    # removed {:ecto_sql, “~> 3.0”},
    {:postgrex, “>= 0.0.0”},
    {:phoenix_html, “~> 2.11”},
    {:phoenix_live_reload, “~> 1.2”, only: :dev},
    {:gettext, “~> 0.11”},
    {:jason, “~> 1.0”},
    {:plug_cowboy, “~> 1.0”}, # note the change
    {:veil, “~> 0.2”}
  ]
end

or maybe you can “override” the :crontab's ecto version restriction with

defp deps do
  [
    {:phoenix, “~> 1.4.0”},
    {:phoenix_pubsub, “~> 1.1”},
    {:phoenix_ecto, “~> 4.0”},
    {:ecto, "~> 3.0", override: true}, # note the change
    {:ecto_sql, “~> 3.0”},
    {:postgrex, “>= 0.0.0”},
    {:phoenix_html, “~> 2.11”},
    {:phoenix_live_reload, “~> 1.2”, only: :dev},
    {:gettext, “~> 0.11”},
    {:jason, “~> 1.0”},
    {:plug_cowboy, “~> 2.0”},
    {:veil, “~> 0.2”}
  ]
end
12

The second solution worked (I’ve not tried the first one :slight_smile:).

Thank you very much indeed for your fast and complete answer!!

13

Or try sans_password?

1 Like