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 
man, time flew so fast. yesterday it was v1.3 and eex then now v1.6 and heex. I cant keep up
Wait what happens in Laravel world? Generators are not optional? How can generators be not optional? 
It is completely optional. And despite my statement above, I had used it even before 1.6 and had little to complain about. It’s just that I would have liked it as a separate library instead of a baked in one. But it is a very mild feeling.
Nono, that’s not what I meant, sorry I was just poking fun at how each Laravel project comes (or came in the past, they might have changed that in recent years) with a User model for some reason.
Edit & note: though I am definitely biased and might be latently salty over the fact how Laravel tried to kill the Vapor framework a few years ago by introducing their Laravel Vapor under the same name, despite Taylor being well aware of the original Vapor’s existence. Total 
y move in my books.
Wow til Laravel has both Elixir and Mix.
Seriously? I did not know that about Laravel Elixir! That’s seriously shady as heck.
I guess if you can’t or don’t want to compete on the quality of your product, you can always stoop down to the mud of dirty SEO tricks.
I tried searching the Internet for blogposts scolding Laravel for this predatory naming which at this point really can’t be a coincidence, but could not find anyone being bothered by this… am I too sensitive? I wonder what are other people thinking, though this could perhaps easily be separated into a stand-alone thread as it’s not all that related to Phoenix in the end. Sorry for derailing the celebration of an awesome Phoenix release!
It’s not an option like --no-webpack, but You are free to use it, or not 
It is the post says, however such a default means it will be used by many people, and eventually lock themselves into the style due to nothing pushing them to a better way. Defaults are incredibly important. I don’t worry about the people who already know better, I worry about the people who don’t.
