The accounts package has become pretty central to all of our Meteor apps. I love it for its simplicity, but worry for its future. It hasn’t gotten a lot love beyond its conception, and I anticipate many of us are dependant on it and also have growing needs.
I’m curious if it will grow and evolve with the coming changes to Meteor (database agnostic, new data layer support, etc) or if we are safer using some kind of authentication system from the NPM world.
It’s not going away! We are working with a team from a production meteor app to make it database-agnostic for the future.
I don’t want to say who it is to avoid committing them, but we’ll have more info as the project gets started!
Does that mean that the API will remain the same? For example, the same OAuth endpoints?
Yes, we will try to make this happen. But it is much, much too early to tell exactly what it is going to look like. The main thing I’m trying to say is, the plan is to keep it maintained and working in the face of future changes to Meteor.
Does that mean meteor will finally address limitations regarding _id generation? Specifically the user collection does not support ids generated by mongoDB.
Yeah ideally you will be able to switch out the backend of accounts as you like, so it could include additional options for MongoDB.
I just pray to Jeebus that this doesn’t change as it’s soooo buttery smooth to use.
Meteor.loginWithFacebook({}, function(err) {
if (err) { throw new Meteor.Error("Facebook login failed"); }
});
Good news! If you guys need an extra set of eyes, I’m happy to provide feedback.
Dido there, I do have fairly extensive auth experience within enterprise premises, ldap et al, I’d love to lend a set of eyes to share some experience and provide some insight into especially what the enterprises would rather see.