lai

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

1 reply

sashko MDG Staff

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…

rozzzly

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.

1 reply

sashko MDG Staff

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 reply

rozzzly

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.

ergusto

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.

1 reply

elie

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.

sashko MDG Staff

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 reply

merlinpatt

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?

repsonsive

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