Sending and validating Lambda code to DynamoDB - node.js

Question

I have a Lambda node.js function like so:
function storeUser(email, username, password, salt, fn) {
// Bytesize
var len = 128;
crypto.randomBytes(len, function(err, token) {
if (err) return fn(err);
token = token.toString('hex');
dynamodb.putItem({
TableName: "Users",
Item: {
email: {
S: email
},
username: {
S: username
},
passwordHash: {
S: password
},
passwordSalt: {
S: salt
},
verified: {
BOOL: false
},
verifyToken: {
S: token
}
},
ConditionExpression: 'attribute_not_exists (email)'
}, function(err, data) {
if (err) return fn(err);
else fn(null, token);
});
});
}
The event handler is like so:
exports.handler = function(event, context) {
var email = event.email;
var username = event.username;
var clearPassword = event.password;
computeHash(clearPassword, function(err, salt, hash) {
if (err) {
context.fail('Error in hash: ' + err);
} else {
storeUser(email, username, hash, salt, function(err, token) {
if (err) {
if (err.code == 'ConditionalCheckFailedException') {
// userId already found
context.succeed({
created: false
});
} else {
context.fail('Error in storeUser: ' + err);
}
} else {
context.succeed({
created: true
});
}
});
}
});
}
I want to make the username and email unique. How do I ensure that in the write to the db and if one (or both) is not unique, get an error back saying which is not unique?

Answer 1

This is a quick and dirty way to do it. It's not extraordinarily efficient but it gets the job done:
const // You want const because no required packages ever change at runtime
AWS = require('aws-sdk'),
ddb = new AWS.DynamoDB();
exports.handler = function(event, context) {
// QUERY USERNAME FIRST
var table = 'tableName';
var paramsUNCheck = {
TableName : table,
ProjectionExpression : 'hash',
KeyConditionExpression : 'hash = :v_hash AND range = :v_rng',
ExpressionAttributeValues : {
':v_hash' : { S : 'hash' },
':v_rng' : { S : event.username }
}
}
ddb.query (paramsUNCheck, function(err, data) {
if (err) {
context.fail (JSON.stringify(err, null, 2))
} else {
if (data.Count === 0) {
var paramsEMCheck = {
TableName : table,
ProjectionExpression : 'hash',
KeyConditionExpression : 'hash = :v_hash',
FilterExpression : 'email = :v_eml',
ExpressionAttributeValues : {
':v_hash' : { S : 'hash' },
':v_eml' : { S : event.email }
}
}
ddb.query (paramsEMCheck, function(err, data) {
if (err) {
context.fail (JSON.stringify(err, null, 2))
} else {
if (data.Count === 0) {
// REGISTER IF IT PASSES ALL CHECKS
var paramsReg = {
TableName : table,
Item : {
'hash' : { S : 'hash' },
'username' : { S : event.username },
'password' : { S : event.password },
'email' : { S : event.email }
}
}
ddb.putItem (paramsReg, function (err, data) {
if (err) context.fail (JSON.stringify(err, null, 2));
else
context.succeed ({ done: 'yes' });
});
} else {
context.succeed ('Email already used, please try again.')
}
}
});
} else {
context.succeed ('Username taken, please try again.')
}
}
})
};
Now, the reason why I say this is a dirty way of doing it is because you do two queries.
With that said, running reads is significantly cheaper than running writes. The reason for this madness:
One read capacity unit = one strongly consistent read per second, or two eventually consistent reads per second, for items up 4 KB in size.
One write capacity unit = one write per second, for items up to 1 KB in size.
From here
Basically, it's way cheaper to run two read requests then one write request. PER PROVISIONAL THROUGHPUT the cost is ~$0.09/ read throughput and ~$0.48/ write throughput.
But wait, don't you have to do a write anyway? Well, yes you do, but it's a write that should always succeed. What if you have a user constantly hitting that lambda? You'll want a read on the front line of defense and not a write. Basically I'm as cheap as possible. I'll crank read throughput all day long if it means not 'uping' the write (within reason).
The other way to do it is Conditional Writes and you're going to want to check begins_with usernameofemail#gmail.com all the way up to the end - basically forcing a full string check, so disregard the "begins with".