Are there any good user accounts packages that would fit well into a private application?

help
1

I’m building an application for a client that needs it to be private, meaning there won’t be any public user registration. User accounts/profiles will be added to a custom collection, in-house, via a separate app they currently use for other administrative tasks, and the login credentials will be sent out to users who have applied and been approved to use it.

So, my question is are there any good accounts packages out there that fit this method? Something that doesn’t need to use the regular Meteor Users collection?

My first instinct is to just create my own custom accounts system, but I figured I’d check to see if anyone is using any nice packages, or has been able to tweak the accounts-password or any other commonly used packages to tackle this kind of scenario.

As somebody still fairly new to Meteor, and really just app development in general, any sort of advice would be greatly appreciated.

2

Any particular reason why?

You can choose to not use the UI and not provide a registration option, if that’s the only thing holding you back.

There are a lot of benefits gained from using the built in accounts system so I wouldn’t be quick to ditch it unless there’s a solid reason for it.

1 Like
3

In principle, I agree with Nathan.

You don’t have to present a registration option. You can use the enrolment function to send tokens that initiate a user login.

1 Like
4

I developed an app like this that is in production.

You don’t have to allow people to register. There’s a configuration option (forbidClientAccountCreation) for this exact reason.

1 Like
5

Thanks a lot for the responses, guys. Sorry I couldn’t get back sooner.

So, my reasoning behind thinking I shouldn’t use the users collection is simply that I was struggling to customize it. I should mention that I’ve been using the useraccounts package by splendido in my initial attempts to get this working the way I want it to, and it is very easy to customize the UI, and not provide a registration option, etc… (There is also a version of useraccounts styled for meteor-ionic, which is the framework I’ve chosen to go with, so it’s great.)

But, like I said, I was having a hard time figuring out how to customize the users collection to fit my needs. I added a new field via my Mongo GUI tool (MongoVue), but I couldn’t access or even find that field from within the application. So, I figured it would just be easiest to create my own accounts system with my own custom collection that I could make to match the external collection that the owner of the app will be using to register new users, if that’s what I needed to do.

HOWEVER, after talking it over with one of my partners on this project yesterday,
it looks like we are electing to actually offer the registration button to new users because we want them to generate their own password from the start, as well as their username. So, we’ll also be trying to stick with the normal users collection. (Which it looks like you guys were going to convince me to do anyway :slight_smile: .)

Our thinking is that, before being able to use the app, the user has to have been approved by the app owners, which has always been the case. After the user has applied and been approved, they will have an email on file with the owner, which we will store as part of a separate userprofile collection. Upon registration, we need to check that the email the user is attempting to register with is present in our userprofile collection, and that it doesn’t have a password attached to it, meaning nobody has registered with that email yet. Otherwise, the registration fails. This way once the user is registered, we can grab a manually assigned ID in that userprofile collection whenever they log in that will be used to grab all of the appropriate data/content for them.

Does this sound like a good approach?
Does it sound easily achievable?
Are there any obvious obstacles I’m overlooking?

Sorry to give you so much to read. I got really excited when I came back and saw your responses. Thought I should be as thorough as possible.

Thanks again for any help.

6

This is almost the same approach I use in a production app. I have a UserProfiles collection which is built from an external data source (an accounting program). When a user tries to register, there’s an onCreateUser hook that checks if the email matches one already in the UserProfiles collection - and if so - grants an 'employee` role (alanning:roles). Only then will the user have access to anything in the app. This approach works well - just gotta make sure you control your methods and publications. I believe you can also just reject the registration in the onCreateUser hook.

1 Like
7

Awesome! Thanks for your input. This makes me feel a little more at ease approaching this (There’s still some other functionality of the app I’m working on before get to tackling registration and login).

What, exactly, do you mean by controlling the publications and methods? Ensuring that sensitive data isn’t published until the login occurs?

8

I mean ensuring that sensitive data is always role-checked

Meteor.publish('foo', function () {
	if (Roles.userIsInRole(this.userId, ['employee']) {
		return Foo.find({});
	}
});

Meteor.methods({
	foo: function () {
		if (Roles.userIsInRole(this.userId, ['employee'])) {
			return true;
		}
	}
});
1 Like