Why doesn't Accounts.createUser create a user in MongoDB? - mongodb

I'm using accounts-password package to manage my user accounts. I tried 2 ways to create account using Accounts.createUser() function.
1st way: Calling Accounts.createUser() from the client
register.js:
Template.register.events({
"submit form"(event){
event.preventDefault();
const email = event.target.email.value;
const password = event.target.password.value;
Accounts.createUser({
email: email,
password: password
});
}
});
2nd way: Calling Accounts.createUser() from the server method and calling that method from the client. Got the hint after going through: Meteor: Accounts.createUser() doesn't create user
register.js:
Template.register.events({
"submit form"(event){
event.preventDefault();
const email = event.target.email.value;
const password = event.target.password.value;
Meteor.call('createNewUser', email, password);
}
});
methods.js:(on server)
Meteor.methods({
'createNewUser'(email, password){
Accounts.createUser({
email: email,
password: password
});
}
});
In both the cases, no new collection is created in MongoDB. Neither is any old collection updated. My connection strings are proper. Why is this happening?
However, when I use the following on the server, a document is created:
Accounts.users = new Mongo.Collection("profiles", {
_preventAutopublish: true, _driver: dbConn
});
Meteor.users = Accounts.users;
I don't know why a new collection has to be created for this to work. Isn't accounts-password package supposed to create a collection by itself?

if you are just keen on getting a basic version up and running try adding the default {{>loginButtons}} to your html. This will also make sure the javascript is executed as it should be. Building the js manually only makes sense if you need more customizability.

Have you added the accounts-base package? Accounts.createUser comes from this package. (docs)
In the linked example you gave, the OP had set forbidClientAccountCreation: true in the Accounts.config(). That prevents the Accounts.createUser function from working on the client (which is useful in applications where users need an invitation to register). That is why the answers recommended to create the user account server side and isn't applicable to your application.
As a side note, in your second example you are passing an unencrypted password from the client to the server which is considered dangerous.
You can encrypt it before sending it to the server method like so:
const password = Accounts._hashPassword( event.target.password.value );

_driver: dbConn
That line is really concerning. Are you trying to manage your own database connection?
There's nothing wrong with the code you wrote, it's not your problem. Accounts.createUser is the correct method to call.
If you need to use a different database than the one initialized by default by running the meteor command from terminal, look at the documentation on using MONGO_URL.

Related

How to add auth endpoints to existing Sails V1 project?

I have an existing Sails V1 project that was generated as an empty app (it uses a React front-end). I'd now like to add in the auth endpoints that would have been created if the app had been generated as a web app. Is that possible?
Yes, it is possible.
You need to hook up the policies and related actions. Your best bet, I would say, is to generate a new project, with the front-end included, and see how that is set up. It utilizes the policy-middleware to call the policy-actions.
module.exports.policies = {
'*': 'is-logged-in',
// Bypass the `is-logged-in` policy for:
'entrance/*': true,
'account/logout': true,
'view-homepage-or-redirect': true,
'deliver-contact-form-message': true,
};
Here you see that the policy.js in the /config folder, calls is-logged-in for all controllers by default. You also see that there is some exceptions added below.
is-logged-in is the file /api/policies/is-logged-in.js:
module.exports = async function (req, res, proceed) {
// If `req.me` is set, then we know that this request originated
// from a logged-in user.
if (req.me) {
return proceed();
}
// Otherwise, this request did not come from a logged-in user.
return res.unauthorized();
};
This is the part that does the check for the logged-in status of the user. You can see that it uses the req.me part, which is set up in the api/hooks/custom/index.js. Here it loads the user from the database and makes the logged in users data available on the req object.
If you don't have, or want to use, this hook, you can exchange req.me with req.session.userId, assuming that you set the userId on the session-object on your login-handler. Example from Sails-code:
....
var userRecord = await User.findOne({
emailAddress: inputs.emailAddress.toLowerCase(),
});
// check user exist
....
// check password
....
//check remember-me
....
// Modify the active session instance.
this.req.session.userId = userRecord.id;
// Send success response (this is where the session actually gets persisted)
return exits.success();
....
I hope this gets you on the right path, at least in terms of where to dig deeper.

Meteor - Password recovery / Email confirmation dynamic url

Basically, I'm using the accounts-base package on meteor and on meteor startup, I set up what template the server should use for the password recovery mail, email confirmation mail, etc.
For example, in my server/startup.js on meteor startup I do many things like :
Accounts.urls.verifyEmail = function (token) {
return Meteor.absoluteUrl(`verify-email/${token}`);
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
return EmailService.render.email_verification(user, url);
};
The problem is that my app is hosted on multiple host names like company1.domain.com, company2.domain.com, company3.domain.com and if a client wants to reset his password from company1.domain.com, the recovery url provided should be company1.domain.com/recovery.
If another client tried to connect on company2.domain.com, then the recovery url should be company2.domain.com.
From my understanding, this is not really achievable because the method used by the Accounts Package is "Meteor.absoluteUrl()", which returns the server ROOT_URL variable (a single one for the server).
On the client-side, I do many things based on the window.location.href but I cannot seem, when trying to reset a password or when trying to confirm an email address, to send this url to the server.
I'm trying to find a way to dynamically generate the url depending on the host where the client is making the request from, but since the url is generated server-side, I cannot find an elegent way to do so. I'm thinking I could probably call a meteor server method right before trying to reset a password or create an account and dynamically set the ROOT_URL variable there, but that seems unsafe and risky because two people could easily try to reset in the same timeframe and potentially screw things up, or people could abuse it.
Isn't there any way to tell the server, from the client side, that the URL I want generated for the current email has to be the client current's location ? I would love to be able to override some functions from the account-base meteor package and achieve something like :
Accounts.urls.verifyEmail = function (token, clientHost) {
return `${clientHost}/verify-email/${token}`;
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
return EmailService.render.email_verification(user, url);
};
But I'm not sure if that's possible, I don't have any real experience when it comes to overriding "behind the scene" functionalities from base packages, I like everything about what is happening EXCEPT that the url generated is always the same.
Okay so I managed to find a way to achieve what I was looking for, it's a bit hack-ish, but hey..
Basically, useraccounts has a feature where any hidden input in the register at-form will be added to the user profile. So I add an hidden field to store the user current location.
AccountsTemplates.addField({
_id: 'signup_location',
type: 'hidden',
});
When the template is rendered, I fill in this hidden input with jQuery.
Template.Register.onRendered(() => {
this.$('#at-field-signup_location').val(window.location.href);
});
And then, when I'm actually sending the emailVerification email, I can look up this value if it is available.
Accounts.urls.verifyEmail = function (token) {
return Meteor.absoluteUrl(`verify-email/${token}`);
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
const signupLocation = user.profile.signup_location;
if (signupLocation) {
let newUrl = url.substring(url.indexOf('verify-email'));
newUrl = `${signupLocation}/${newUrl}`;
return EmailService.render.email_verification(user, newUrl);
}
return EmailService.render.email_verification(user, url);
};
So this fixes it for the signUp flow, I may use the a similar concept for resetPassword and resendVerificationUrl since the signupLocation is now in the user profile.
You should probably keep an array of every subdomains in your settings and keep the id of the corresponding one in the user profile, so if your domain changes in the future then the reference will still valid and consistent.

How to get the current user using jsonwebtoken in Sails.js?

I've been working with Sails since couple of weeks ago, I came from Rails and I don't have any experience working with Node.js.
Now I'm trying to make a robust token authentication using jsonwebtoken.
https://github.com/auth0/node-jsonwebtoken
I followed this guide http://thesabbir.com/how-to-use-json-web-token-authentication-with-sails-js/ and everything worked fine.
I'm able to make a sign up, sign in and then use the token correctly for different actions.
Now, there are some actions where I'd like to use the login user,
something like devise current_user helper.
For example, when creating a comment, this comment should belongs to the current user.
Using Sabbir Ahmed guide, in the line 33 from the isAuthorized.js policy the token gets decrypted so I can get the current user id from there.
So, my question is, what should be the best way to get the current user and be able to use it later in some controller?
For example I tried something like:
# isAuthorized.js line 34, after getting decrypted token
User.findOne({id: token.id}).exec(function findOneCB(err, found){
currentUser = found;
});
But, on this way, because this is an async action I can't use this currentUser in a controller.
I want to store the current user in order to be able to use it later in some controller without repeated the same code in each controller, something like a helper or maybe a service.
The trick is where you place the next(). Since you are making an async call, the control should only be transferred to next policy/ controller once the database action is competed.
You should modify the policy to:
User.findOne({id: token.id}).exec(function findOneCB(err, found){
if(err) next(err);
req.currentUser = found;
next();
});
And you should be able to access the user details in controllers that use isAuthorized policy via req.currentUser
If by
For example, when creating a comment, this comment should belongs to the current user.
what you mean is certain attributes like username, and country etc, rather than querying the database after verification, what you can choose to do is to send these additional attributes to jwToken.issue in api/controllers/UsersController.js
eg.
jwToken.issue({
id: user.id,
username: user.name,
country: user.country
})
How that helps is, you can keep api/policies/isAuthorized.js as is, and in all the controllers that you use in the future, you can access the payload values from as
token.username or token.country
Instead of having to query the database again, thereby saving you valuable response time.
Beware however, of the data you choose to send in the token (you could also send {user:user} if you want to) however, as the secret key or hashing is not required to decrypt the payload as you can figure # jwt.io , you might want to exercise restraint.

How to send final response from findOne() callback?

I have a User controller that has a create method that checks the database for email and username uniqueness before creating the user (this is to work-around a bug in the mongodb adpater for SailsJS that doesn't honour the unique attribute flag - version 0.10.5).
The code looks like the following:
User.find({ email: req.body.email }, function (err, user) {
if(user) {
return res.badRequest('Unique email constraint. Email is already used.');
}
});
User.create(req.body).exec(function (err, user) {
// Code to catch and manage err or new user
}
What I expect is that if the email already exists in the database (mongodb), to send a 400 using res.badRequest(), then execution to end.
What happens is that the response is sent, but then control moves to User.create() - execution doesn't end. I suspect that return res.badRequest is returning control back to the calling function (User.findOne), and execution continues from there.
I tried using res.badRequest().end() but that leaves the client hanging (there is no response), and using res.end() after the return res.badRequest() generated 'header send' errors.
How do I have execution of this request end if an existing email is found?
First of all, your findOne is here a find. That's not related to your problem, but it is slightly confusing, and you should ensure you are getting data in the format you expect.
As for finishing the request after marking it bad, I have not used sails, but I was able to end execution in the past by using res.send(). EDIT: after looking at the docs, it seems this is done for you by .badRequest(), so ignore that part.
That said, even THAT is not actually your problem. Your problem is that you start an asynchronous User.find(), and then you immediately start running User.create() (also asynchronously), and so your request doesn't get marked bad until after you have already attempted to create a new user.
What you need to do is one of two things:
Use promises (NOTE: this is how it works for Mongoose; Sails may be different) to only run User.create() after User.find() has completed. e.g;
var userQuery = User.findOne({ email: req.body.email }).exec();
userQuery.addBack(function(err, user) {
if(!!user) res.badRequest('...');
else create_user();
});
Put your user creation logic inside of your findOne block. e.g.;
User.findOne({ email: req.body.email }, function(err, user) {
if (user) { // or perhaps you want if (!err)
User.create(...);
} else {
// handle error
}
});
Personally, I would advise that you use promises (especially later, when you have long chains of requests happening one on top of the other), but take your pick.

authorization with socket.io

I'm attempting to determine how best to authorize (in addition to authenticate) a user to perform a specific task using socket.io.
In express, this is fairly straightforward. I first have a login/password form that queries the database to determine if the record exists, and if it does exist, then I attach the User to the req.session data.
exports.session = function(req, res){
User.authenticate(req.body.username, req.body.password, function(err, user){
if (user){
req.session.user = user;
res.redirect('/');
} else {
console.log("authentication failed");
res.render('user/login');
}
});
};
And once I have this, I can use middleware to authorize certain requests. For example,
app.put('/api/users/:userId', m.requiresLogin, m.isUser, api.putUser);
//Middleware
exports.isUser = function(req, res, next){
if (req.session.user._id == req.user._id){
next();
} else {
res.send(403);
}
};
But I'm a bit confused about how to do this using socket.io. Say I have a event listener which alters a user's profile in the database, given that user's profile JSON object.
socket.on('updateProfile', function(data){
// query the database for data.user._id, and update it with the data attribute
// but only do this if the data.user._id is equal to the user trying to do this.
});
Any suggestions as how to achieve this? Can it be done through the session information?
It appears as though you're using Express.
I would highly recommend Express middleware called Passport (https://github.com/jaredhanson/passport).
Using Passport, you can implement any number of strategies to authenticate users (ex. OpenID through Google, Yahoo, Facebook; OAuth through Twitter, Facebook; or local strategies (ex. email registration)).
Finally, to answer your precise question: a project called passport.socketio is amazing in that it plays well with the above authentication strategies and, if you set Express's session, it will play well with that too. (https://github.com/jfromaniello/passport.socketio)
See the documentation here:
https://socket.io/docs/migrating-from-0-9/#authentication-differences
io.set('authorization', function (handshakeData, callback) {
// make sure the handshake data looks good
callback(null, true); // error first, 'authorized' boolean second
});