Phoenix 1.6.0 got released last week, with built-in authentication and mailer generators, a whole new HEEx (HTML-aware Embedded Elixir) engine, and esbuild integration (which replaces former Node.js and WebPack integrations!).
Have you already had a chance to check out what’s new yourself?
This is a great Phoenix release!
Having auth built in has been one of my most wanted features for a long time and I think will help make it easier to build packages that make use of the unified system 
It’s also great to see LiveView becoming more and more refined with each release 
I am not sure whether there are any immediate plans for it, but I might wait to get back into reading Programming Phoenix until it is updated for 1.6 (I’ve still got Programming Erlang to finish first! 
)
Looks like an awesome release!
However, the auth system is… odd, I really think that self-hosted authentication is the wrong way to go in today’s online climate, and generating that as a kind of default is really bad for security and end-user usability both and encouraging it is really the wrong move. A pluggable third-party auth system would have been far better, especially as you could put in a local auth if you really really wanted to within it, but by not supporting that as the default is just going to encourage poor design to begin with…
I prefer local auth 99% of the time and I also prefer not to use external packages if at all possible - having auth built in like this makes it safer for those who prefer to do the same.
It doesn’t surprise me that it was also one of the things people loved about the Vol framework, as the unified system made it easier to create sharable components that could make use of it.
For people who don’t want it… they don’t have to use it
You can prefer local auth sure, but having that be the only option is very bad for security and end-user accessibility. As stated, it should have been a pluggable framework, which could have various defaults for things like local auth or OIDC or so, but at this point adding in a third-party to the generated source after the fact is a lot more work, so much so that the generated bit is just going to slow it down at this point as it’s just going to make it hard to unify the accounts.
I’m sure it won’t be to everyone’s tastes but I personally love that it is included 
For many projects I do not want to rely on third parties or over complicated libraries when I just want something more simple or customisable for my specific needs.
I think it’s good to include auth, the issue I take is that they chose the form that is both worst on security and the worst to fix/extend with a better one. I.E. people that actually know about security won’t touch it, and thus it was wasted. They could have done it properly and still been just as easy to instantly use and all, but they didn’t…
You could always suggest PRs… but I would definitely understand why they’d want to keep it simple (as I’d prefer that myself too - I just want a starting point as that’s what most apps will need at the very least)
Seems too late to PR at this point, that broken design wouldn’t be forwards compatible with a better design. A starting point is good, but this is a starting point that is not easily extendable into something good though, a starting point that you can then easily extend into something good is far better.
Hmmm I will reserve judgment until I’ve had a proper chance to use it then, but from what I saw it looked pretty good to me
Hopefully I will get back to Programming Erlang soon and then Programming Phoenix after that - tho I am hoping PP is updated to 1.6 by then…
The issue though is that the “using it” is only local auth, bad for end-users and bad for security, so the ‘using it’ is the issue… ^.^;
Hmm… I can see the argument for wanting to have a nice and clean integration with third-party auth services, but I’m really not sure if I’d ever want something that big, potentially brittle (services may and will go down eventually, protocols might change over time) and reliant by nature on services outside of your sphere of influence in the core of the framework… (Edit: I mean, exactly trying to get rid of things that the Phoenix team can’t easily fix on their own is one of the reasons to get rid of their prior Node.js/WebPack integration, so…)
And I know this differs greatly by everyone’s day-to-day job, but in the past three and half years in my current company, only once did our client require the usage of a third-party auth provider. That’s partially due to the fact that third-party auth providers are just not all that common (if at all) when used for authenticating for, say, admin panel purposes, but even then – that one time when we had to deal with a third-party auth system was when login through LINE (and only LINE) was required – that’s due to the local popularity of the LINE service in Japan, but point is – I don’t think LINE is popular globally, so I doubt it would be realistic to hope for any sort of tight integration with the LINE Login platform 
The reason why local auth should not be used in many-faceted, but that doesn’t mean you have to use someone else. I host my own OIDC server for my services (which it itself also has a local login, or other auth to github, google, and a few others), that’s fine, but it should not be in the webapp itself, that’s not its job at the very basic.
Side topic, It’s interesting how much their new HTML-eex engine is copying even more of what Drab did years ago (though it looks like it’s missing some abilities that drab had like fast in-place identification and replacement for the live swaps)… Still irritated about all that… >.>
Own OIDC server, that would be something like Keycloak or maybe FusionAuth (never used before, just had a quick search)? I’d be more inclined to employ that for sure, it’s just… I can see both how it would be a better security practice, that’s for sure, but at the same time, I can understand the team’s reasoning for wanting to ship something that’s reasonably secure (it still is better than trying to write your own auth system) and works out of the box, without any need for deploying a side-service, additional configuration, etc.
(Plus again, probably not very related to others but when we try to suggest things like that to our clients, they are not very often on board, for various reasons… even relatively insignificant things like increased infrastructure cost due to having one more ECS service running are a factor, unfortunately…)
There’s tons of them, I’ve been using Ory Hydra due to open source and very easy to set up and plug in your own pages and handling.
That would absolutely not be local auth. It doesn’t matter the language, the libraries, I wouldn’t do it in elixir or rust or C.
And regardless, they could have shipped a local auth as a “Default” for an authentication setup, but right now it’s not a default, it’s the Only thing, it doesn’t plug with anything else if someone wants to. Doing it the way they did just encourages using the worst method for security in authentication, sure it could still be a default as long as it would be trivial to switch to something better (like giving an OIDC connection string to, say, transparently then just switch to using that OIDC server or whatever, there’s so many choices), but it should not be the only especially being hard to switch out and remove later for something better instead of being easy to switch.
The date of that blog post is in August. I don’t remember 1.6 releasing that long ago?
Looks like it’s the RC announcement updated for the final release Mafinar
I realized that later. This is why I prefer immutable data. Less confusion lol.
I have been using Phoenix 1.6.0-rc and love it. I am not sure how I feel about the auth generators being included though (never a fan of generators but I can see why they’d be useful).
Most importantly, anyone who ostracizes webpack from their territory immediately gets 5* from me!
I haven’t tried the version 1.6 yet, but assumption was like there would be an option to use phoenix without it like you can use the --no-ecto option. Is that not the case with auth?
I think that the integration is completely optional and only takes on a form of a generator. If you don’t invoke the generator in the first place, you won’t get the built-in authentication mechanics.
I mean, not everyone is as crazy as those Laravel folks 
Sorry 
