[sansnomme]

The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community. Problem is, the ones available are mostly extremely low level (ueberauth, guardian etc.) and you have to spend ages customizing it. On Rails it's literally two commands to set up user registration, email confirmation, password reset. Despite its supposed Rails roots, Phoenix has a long way to go (the greater irony is that the company behind Devise, Platformatec, is also the company behind Elixir).

If you only need basic functionality and absolutely have to use Phoenix, Pow is a good choice:

https://github.com/danschultzer/pow

[nickjj]

I can't speak for the Phoenix dev team but the fact that some of the Devise authors are now heavily invested in Elixir / Phoenix and they didn't port Devise to Phoenix by now makes you wonder if they still think the idea of Devise is a good one.

Personally I haven't found auth to be a problem in Phoenix and I have lots of experience with Rails (and using Devise).

You can put together an iron clad user registration + auth system in about 150 lines of app-level code (not including lines of code for the template forms, but with Devise you would end up customizing your own forms anyways). This includes registering new users, authenticating by email + encrypted password, logging in, logging out, session management and having the idea of a current_user in your system, along with a way to restrict routes, controllers or actions to only logged in users. The essentials basically.

I would much rather manage ~150 lines of code in my own project that I fully know and can easily customize than pull in something like Devise which is 6,000+ lines of Ruby and have to configure / override a number of things.

Everyone has their own opinions but I would much rather spend my time developing features for my app than trying to figure out how to customize a massive third party dependency.

Personally I'm rolling with a magic link authentication system in my Phoenix app and it was also around 200 lines of code to implement everything, including configuring and sending the emails out. There's no external libs beyond Phoenix to get it all working (except for sending the emails out, in which case I use Bamboo which is a lib dedicated to sending emails).

[bitscrapper]

As someone who used Devise multiple times and always ended up regretting said choice in the long term, I am actually glad there is no Devise for Phoenix.

In one day I can quickly get something up and running with Guardian and have full control over how my app does authentication. Password reset and confirmation are easily done with Phoenix.Token without a need to touch the database.

Also, authorisation is a breeze on Phoenix. Take a look at Canada: https://github.com/jarednorman/canada - and it is only 10 LOC.

[pbowyer]

> The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or Django. The framework authors refuse to ship a first party implementation and instead leave it to the community.

I agree, but it's not unique to Phoenix. In the PHP world the otherwise excellent Symfony framework is only starting to add generation of authentication/authorization, and email confirmation and password reset remains the developer's responsibility.

I see two reasons for this.

1. Frameworks see themselves as building blocks, not RAD systems. When the core framework developers are (mostly) working on APIs they don't see the need for approval/password reset. After all "you'll issue the user with a JWT so who cares about the rest (shrug)"

2. Flexibility to auth with anything. Apparently not bundling a system makes it more "flexible".

I believe (1) to (a) be shortsighted and (b) we need RAD frameworks, of higher-level flexible components that can be bolted together.

I believe (2) is wrong, and bundling standard auth flows does not reduce flexibility: you implement your own if you need something else.

[conradfr]

That's partially true because you have FosUserBundle as kind of defacto standard for user facing auth (but yes it's a community package) and many built-in things for APi auth.

[pbowyer]

FosUserBundle is no longer recommended, and is superseded by Guard. Guard is considerably nicer to work with, and doesn't take long to build the extra bits (password reset etc) but (a) it's not built-in, and (b) if done as a bundle, it doesn't get the same level of support.

[mmartinson]

>> The framework authors refuse to ship a first party implementation and instead leave it to the community

Maybe for AuthN, but AuthZ is pretty far from the business of a web framework. The framework authors seem, for the most part, to be avoiding first-party endorsement of secondary tooling that doesn't deeply benefit from being first-party. I find it super refreshing coming from Rails where it is either the golden path or good luck.

A lot of the early AuthN libraries seem to target the controller layer, but I've found, having worked on a couple of sizeable Phoenix production codebases, that AuthN at the app domain layer works better. Regular use of channels as an alternate entrypoint to web request controllers means that controller based helper libraries are less valuable. Once you push this logic inside the app domain, it really isn't the business of Phoenix to know or care about it, since you're just working in plain Elixir, probably with some sort of Ecto struct to represent identity.

[di4na]

I would like to point out that it is not only the company but the person behind Devise (ie José Valim). It may means, possibly, that they are not really a fan of what was created with Devise and think the experiment should not be replicated. You know.