Built in user accounts in Phoenix (Meteor and Node have them)

What are people’s thoughts on this article?

I think a bunch of people on these forums have come from Meteor including myself. Is there a way to solve these Phoenix difficulties?

Apologies if this has already been posted on the forums.

1 Like

Well it’s possible to develop an integrated package that will give the whole thing out of the box, none have stepped up yet. I doubt there is ever going to be an official integrated authentication system as flexibility is a major selling point for phoenix.

There was a discussion about auth in this thread User authentication in Phoenix?

I think having an opt-out-able system could be really handy - people who don’t want it just opt-out on project creation or delete the associated files/code.

Having all of the files/code generated on creation and part of the app’s visible code (i.e not hidden in the library files or requiring manual generation) would make it super simple to edit or expand the system (one of the biggest criticisms of using third party libraries - at least in the Rails world). It would also allow developers to create libraries based on it and that could result in some really interesting stuff.

Having said that, there could be issues when you come to upgrade, and not everyone wants the same thing out of an auth system - so there’s swings and roundabouts.

Yeah, but really most of us do want the same thing from oauth.

Meteor doesn’t have auth built in. It’s just a package (or packages) you
can add and you’ll be setup with auth in 30 seconds and one line of code if
you want it.

Meteor is also bound to Mongo :roll_eyes: But eventually someone will make an out-of-the-box solution. It’s not up to José or Chris.

I wouldn’t agree with the article’s point of view. It is correct in its statement that everything is perfectly fine unless you need to change one of the things that are “set in stone” as it says. When that happens you’ll be hating life more than anything.

An example analogy I think can be said about using 3rd party services instead of building out a feature yourself. If your requirements happen to fit exactly what the service offers, then you’re golden. The moment that this becomes untrue though you either have to struggle for a very long time or drop the new requirement all together. If you create the requirements AND you develop the features, knowing that limitation will actually box in your requirement creation process without you even realizing it. If you have someone who creates your requirements for you, you’ll know that they never fit squarely into what 3rd party services or in your case packages like this offer.

I see this package as a great tool for prototyping and for new developers to get systems out live into production quickly. But as a user of this package I wouldn’t ever want to maintain any codebase using it as it would be very likely stretching its capabilities very quickly IMO. The elixir community tends to prefer packages that take long term maintainability into account over quick setup (in which then the user has very little understanding of what they just created).

1 Like

Something like this for elixir would also be good. It’s been posted in the past here too.

https://medium.com/the-ideal-system/ooth-user-accounts-for-node-js-93cfcd28ed1a

One of meteor’s mind-blowing features is its out-of-the-box accounts system. In the wider node ecosystem such an easy solution has yet to be found.

I’ve already taken my time to describe the drawbacks of a monolithic framework that takes care of everything for you. It is much better to follow the UNIX philosophy, where an application has different components, each of which does one thing and does it well.

One of these things has to be the management of the user’s identity.

1 Like

There is something similar to this, maybe not 1:1, however, worth to check out. :wink:

2 Likes

I moved your post to this thread and adjusted the title @elie (think it would be good to keep the discussion in one thread) :023:

1 Like

Guardian is a JWT system, a login library would be more like ueberauth/ueberauth, you can have it use JWT or Phoenix session tokens or whatever you want, it does not make the interface for you or the storage, but it handles everything else related to the process of logging in. :slight_smile:

2 Likes