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.
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.
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.
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.
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.
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.
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?
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.
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?
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
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.
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.
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!