Meteor Guide: Users and Accounts

guide
2

It would be great to have a guide that shows us how to a custom authentication system.

2 Likes
3

Here’s an article about how to make a custom OAuth2 handler from @robfallows: http://robfallows.github.io/2015/12/17/writing-an-oauth-2-handler.html

I think there are some articles about making a totally custom handler as well. I know the Rocket.Chat team has a ton of these:

  1. GitLab: https://github.com/RocketChat/Rocket.Chat/tree/develop/packages/rocketchat-custom-oauth
  2. CAS: https://github.com/RocketChat/Rocket.Chat/tree/develop/packages/rocketchat-cas
  3. LDAP: https://github.com/RocketChat/Rocket.Chat/tree/develop/packages/rocketchat-ldap

And more…

1 Like
4

Last time (several months ago) I looked, the official “accounts” suite of packages were utterly dependant upon blaze. Considering the upcoming switch to GraphQL, and the general consensus that react is the prefered solution for UI, are there any plans for overhauling users/accounts/sessions?

Some things that come to mind:

  • from what I read, it sounds like Apollo will be more _REST_y and less _WebSocket_y.
    • are those REST calls going over WS (so server would already have the user’s active session via the socket instance) or would it be HTTP(S) - meaning a session lookup would be required?
    • how would the current session mechanism handle move from stateful to stateless?
  • JWTs?
  • it’d be cool if the new implementation(s) (should there be one) be agnostic to UI, data store, auth mechanism session store, with seperate packages like say meteor-useraccounts-mongo, meteor-useraccounts-twitter, meteor-useraccounts-ui-react, meteor-sessions-rethinkdb, meteor-sessions-redis, etc, etc, etc. A little extra boilerplate for api designers, but some potentially huge benefits. The original packages’ agnosticism to authentication mechanism (eg: password, facebook, google, etc) was awesome! I’d like to see that same philosophy expanded upon.
  • Some type of permissions system? I haven’t really seen any dominate auth/perm libraries out there in the js ecosystem. I suppose this is a void meteor could fill, especially for projects using GraphQL. Meteor’s never really had a sound way to do RBAC. this is definitely * hint hint wink wink * one of the features meteor could tout if it solved.
5

They aren’t utterly dependent - they just happen to include a Blaze template inside that most people don’t even use. It would be pretty trivial to submit a PR to remove that dependency.

We’re currently working with some people from the Rocket.Chat team to decouple the Meteor accounts solution from MongoDB and Meteor itself. So we think it will be possible to provide that to the wider JavaScript ecosystem!

Anyway, I think this is off-topic here; this thread is about the Meteor Guide article and the current recommendations for how to use the current accounts system, not ideas for the future. If you want to talk about it in depth I would suggest starting a new thread.

1 Like
6

Perhaps utterly is too hard a word. And perhaps such a PR might be trivial, yet what about existing projects dependant on those templates? Yeah… not exactly one and done; trivial to submit, nearly impossible to merge.

But, fair enough! I fully understand your desire reserve this topic solely for the discussion of the practices prescribed by The Guide. I merely had a had thought, which is, I supposed, better suited for discussion going forward. I think my concerns/opinions/suggestions certainly do have some merit. Yet, I don’t plan on starting any new topics until I see a little more about Apollo. There will be a time where such a discussion would be more appropriate, and I’ll be certain to copypasta this there.

@sashko I would not be offended in the least if you deleted this post and the two before it. Having been the admin of a forum before, I definitely understand the value of curation.

2 Likes
7

I really like the way the guide recommends adding collection hooks by extending Meteor.Collection and using super calls - how would the guide recommend doing this for the Meteor.users collection? I’d rather not have to bring in a collection hooks package just for this one collection, but can’t see an obvious way to add hooks here in the manner the guide recommends.

8

Would like to see info on merging accounts added to the guide. For example, if someone logs in using Google or Facebook the accounts automatically merge. I know there are some packages that deal with this such as accounts-meld.

1 Like
9

There’s some discussion here:

So far, there doesn’t seem to be an agreement on the best way to do this, and it’s a very touchy security-related issue - doing it wrong could connect the wrong accounts and give your users access to each others’ data. So short of reading all of the source code of the package it’s hard to recommend one unless there is a community consensus.

1 Like
10

Is it necessary to use the onResetPasswordLink and related functions as mentioned in the email flows here? http://guide.meteor.com/accounts.html#email-flows

I’m asking because I’m wondering how to use these with FlowRouter. The guide example indicates that you should display the UI and get the password within the callback

Accounts.onResetPasswordLink((token, done) => {
  // Display the password reset UI, get the new password...

But this seems counter intuitive to me. The UI should be displayed by the router. Plus once I click the link, won’t this callback run immediately? So how do I give the user time to enter the password?

2 Likes
11

I couldnt get accounts facebook, twitter, google and github to work. authorisation kept going to a blank page.

12

just a note that there are 2 links that don’t work:

This is probably better if it redirects to


until there is actually the page reachable on Galaxy or oder server

1 Like
13

I’d like there to be a hook on the server so that I can detect when a user is trying to login with github, which I have set up, so I can permit or deny the login attempt depending on which github account it is.

14

I use typings, and to do what it says in section Custom data about user -> Adding fields on user registration I have to use the Accounts.createUser method in the client and include fields that are not in the meteor Accounts module typings. Should I edit the index.d.ts file in the typings/globals/meteor directory or is there a better way to do it?

2 Likes
15

Hi, sorry if I’m being dim, but in the useraccounts routing section in the Meteor Guide (here), we are told:

Define these routes in a file loaded on both client and server

This is consistent with useraccounts’ own guide, but in the Meteor Todos repo, the routes seem to only be defined in startup/client - see here

So surely this means they’re only loaded on the client if they’re in a client folder - or am I missing something?

1 Like
16

Additionally to the routes definition, with the config being client-only, you can’t make use of e.g. postSignUpHook which are called server-side only - unless you create another config object in a server-side file

Would it not make more sense to put the config in /lib/config/at_config.js as the useraccounts guide suggests?

Or is there a reason for it being client-only in the Todos example?

17

Hmm, I feel like there was a reason but to be honest I can’t remember. Perhaps try moving it to a common file? If it works, please submit a PR to the example app.

18

GLOL

On closer inspection, there is already a PR moving the file from /startup/client to /startup/both - here, so I won’t muddy the waters as this is only slightly different to the way I’ve done it.

19

Hi there!
I have a problem with meteor accounts on Mozilla Firefox Mobile browser version 6.1
When I press facebook button system has no reaction. Where should I search a reason? Thanks!

20

Hi…

Can anyone see this, because I need to ask something like in this link?

21

Hi, I am new to Meteor and do it as a hobby, so please pardon my limited understanding. In the “Per-document permissions” section, the helper is defined as

if (!this.userId) {
return true;
}

Would this return true if the user is not logged in? In that case when the user is not logged in, the returned value of the helper function will evaluate to true and the lists can be edited? I am having trouble understanding this function.