I have an application that is entirely React based and it utilises React Router for routing, I also use the accounts-password package to give me a simple accounts system.
This all works fine for login, as I’ve rolled my own login form and just call Meteor.loginWithPassword() to perform the login itself. But then it comes to things like the password reset email URLs & the enrollment email URLs and clearly at present they go nowhere…
So what is the easiest way to implement my own pages for these “extra” bits of accounts functionality? And are there supporting methods, like Meteor.loginWithPassword to allow me to “enroll” someone, etc. ? And if so, how do I go about setting up the routes that will be used, etc?
you could also implement Auth0, a third-party accounts-as-a-service provider. It’s have many more features than Meteor accounts, such as “sign in as user”, and allows you to take you users with you if you ever migrate away from Meteor. We’re using it both Meteor-Blaze and Meteor-React apps.
It’s less about the React bit, and more about the React Router support, ie. None.
And while I may have considered Auth0 in the past, as we’ve got hundreds of users using the old Meteor Accounts package with no issues, I’d like to keep it all the same for ease of porting. (This is old Blaze, Iron Router, etc.)
right, i thought it would solve your issues since that email verifications are handled by auth0 instead of meteor.
We have nearly 5K users, and Auth0 is configured so that whenever an existing user tried to sign-in it will validate their login with Meteor then migrate the user to Auth0. To be honest implementing Auth0 was a lot more work than we expected. But it does have a lot of advantages compared to Meteor accounts, so thought I’d suggest it. Our primary reason switching to Auth0 was so that our current users of “app A” could use their existing account to sign-in to a “app B”–a new service we are launching.
Thanks for the suggestion, but for now, if I can find a way around this issue, I need something relatively quick at this point, so I’ll stick with Meteor Accounts. Once it’s done however, I may well have time to come back and re-look, so thanks for the tip!
Perhaps I need to test this more thoroughly, but my understanding was that the callback was fired by the “hooks” in Iron/Flow Router once it detected the user had been pushed to the “Enrollment URL”, or whatever. If it somehow detects it another way, cookie, or param, etc. then this may well work… I’ll have a lookie.