Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialNiKole Maxwell
11,083 PointsPassword confirmation - add to DB Schema?
Given the code, is it possible to add a password validation field to the DB? Or just completely unnecessary? (note: I cannot run the code myself as there a bunch of errors with bcrypt that bcrypt.js workarounds aren't fixing for me, hence the question)
Here is my line of thought, if the user mistypes their password, this db entry has no validation to account for that and to my understanding the db entry is created which means its created with a potentially bad password from the users perspective.
Is it possible to create an extra field within the schema object that ensures 'password' === 'password confirmation', else "reject" the entire entry and alert the user to reenter or something like that?
Its possible that this will be answered in the coming videos, just curious.
Current Schema
email: {
type: String, // lets them enter a string
unique: true,//checks for other data / same
required: true, // forces input
trim: true //trims unneeded white space
},
name: {
type: String,
required: true,
trim: true,
},
favoriteBook: {
type: String,
required: true,
trim: true
},
password: {
type: String,
required: true //trim not added, never manipulate the password (*BP*)
}//Note there is not a field for confirmation
});
corresponding form entry
2 Answers
miikis
44,957 PointsHi NiKole,
The validation you're referring to is actually implemented later in the course. Maybe you haven't got there yet. If you have completed the course, then look in the POST route for "/register." There, you will find the following check that makes sure the user's first password matches their second password:
// confirm that user typed same password twice
if (req.body.password !== req.body.confirmPassword) {
var err = new Error('Passwords do not match.');
err.status = 400;
return next(err);
}
Seth Kroger
56,413 PointsA password confirmation field normally wouldn't be stored in the database. It's only ever used one time, when you set or reset the password. Since it should be exactly the same as the password, there is no reason to store it and it would be duplicate data.
You would check it after it is submitted in your route, or before you submit with some client-side JS.
NiKole Maxwell
11,083 PointsNot to store "it" itself but rather to store the fact that it matched the first time input...validate it before creating a db entry (before allowing one to be created) by confirming the two match if that makes sense. I've seen this appear as a check box (that yes it did match the first time) in other database applications where security, records, and accountability and even the Business Intelligence behind that fact, matter a bit more. My thinking is that it'd be similar to confirming that a EULA entry has been accepted.
I may be over thinking it for this matter (a sign up form) but the question is valid - is it possible? Perhaps its further in the course, I'm still going through it and we have not yet gone over what that confirmation field is actually spec'd to do.
NiKole Maxwell
11,083 PointsNiKole Maxwell
11,083 PointsThank you! I'm going to go back through that piece because I didn't catch it when I went through it. Saving the code in my notes - thanks! The deeper question that I had is a no though I guess, you can't save something like a count of how many times a user had to try to set up their password before keying it correctly and getting a match because they don't have a "session" or way to store that info prior to having a db entry....right?
(Was thinking in a long term support scenario this might be a way to identify potentially "support heavy" customers up front.)
miikis
44,957 Pointsmiikis
44,957 PointsActually, you can totally do that! That kind of thing is generally referred to as "analytics." And it's actually very simple to pull off. It'll probably be really difficult — or impossible — to know the exact identity of the person whom had trouble typing their password a second time, but you can definitely store a running count of how many times this "trouble" has occured, historically. This kind of anonymized data is used all the time as raw feedback for UX designers. For example, if, say, 80% of attempts to register produced a "passwords don't match" error, you (as a UX designer) will want to rethink/redesign the information architecture of your app. Hope that helps :)
NiKole Maxwell
11,083 PointsNiKole Maxwell
11,083 PointsYup it does - thanks again. In my realm its BI, glad I wasn't too far off in thinking it was possible. So you can do it, just not using the method I was thinking. You rock!