Code before:
async function createUser(user) {
if (!validateUserInput(user)) {
throw new Error('u105');
}
const rules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/];
if (user.password.length >= 8 && rules.every((rule) => rule.test(user.password))) {
if (await userService.getUserByEmail(user.email)) {
throw new Error('u212');
}
} else {
throw new Error('u201');
}
user.password = await hashPassword(user.password);
return userService.create(user);
}
Here's how I would refac it for my personal readability. I would certainly introduce class types for some concern structuring and not dangling functions, but that'd be the next step and I'm also not too familiar with TypeScript differences to JavaScript.
const passwordRules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/]
function validatePassword(plainPassword) => plainPassword.length >= 8 && passwordRules.every((rule) => rule.test(plainPassword))
async function userExists(email) => await userService.getUserByEmail(user.email)
async function createUser(user) {
// What is validateUserInput? Why does it not validate the password?
if (!validateUserInput(user)) throw new Error('u105')
// Why do we check for password before email? I would expect the other way around.
if (!validatePassword(user.password)) throw new Error('u201')
if (!userExists(user.email)) throw new Error('u212')
const hashedPassword = await hashPassword(user.password)
return userService.create({ email: user.email, hashedPassword: hashedPassword });
}
Noteworthy:
- Contrary to most JS code, [for independent/new code] I use the non-semicolon-ending style following JavaScript Standard Style - see their no semicolons rule with reasoning; I don't actually know whether that's even valid TypeScript, I just fell back into JS
- I use oneliners for simple check-error-early-returns
- I commented what was confusing to me
- I do things like this to fully understand code even if in the end I revert it and whether I implement a fix or not. Committing refacs is also a big part of what I do, but it's not always feasible.
- I made the different interface to userService.create (a different kind of user object) explicit
- I named the parameter in validatePassword plainPasswort to make the expectation clear, and in the createUser function more clearly and obviously differentiate between "the passwords"/what
passwordis. (In C# I would use a param label on callvalidatePassword(plainPassword: user.password)which would make the interface expectation and label transformation from interface to logic clear.
Structurally, it's not that different from the post suggestion. But it doesn't truth-able value interpretation, and it goes a bit further.
Notably, that's not what he says. He didn't say in general. He said "for once, [after this already long discussion], let's push back here". (Literally "this time we push back")
I'm not so sure about that. He's making a fair assessment. These are very intricate attack vectors. Security assessment is risk assessment either way. Whether you're weighing a significant performance loss against low risk potentially high impact attack vectors or assess the risk directly doesn't make that much of a difference.
These are so intricate and unlikely to occur, with other firmware patches in line, or alternative hardware, that there's alternative options and acceptable risk.