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 trial

JavaScript User Authentication With Express and Mongo User Registration Storing Passwords Securely

Validating Hash

In this video, Dave notes that the hashed password is visibly there in the database. He also says that we can't check it because the profile still isn't done. When doing this in a real world environment would make more sense to create the profile prior to doing the security piece? That way you can pass it along for UAT - validation of the hashed password rather than just seeing a hash in the db that might have further development issues?

Keeping it in this order I could see a PM having an issue. Is there an advantage of doing it this way or was it done for the sake of learning?

3 Answers

Chris Freeman
MOD
Chris Freeman
Treehouse Moderator 68,423 Points

If I'm understanding the core of your question correctly, you are asking if there is a specific reason the profile creation is delayed until after the user and password are saved.

The answer really depends on the design of the user and the profile models. If the profile model is requires an existing user reference then the user must be saved first before the profile can be saved. Otherwise you would have to write to the database twice: the first to save the profile, then a second time to update the profile with the specific user reference. Creating the user first saves the second database access.

I have seen some solutions that automatically create a profile once the user model is saved to the database by calling the profile creation code from within a call back function called on user creation completion.

Interesting question. Please post back if I've not understood your question or you have other questions.

Edit: fixed typos

Yup I think you got it. The reason I asked was because I wanted to make sure there wasn't a critical dependency that would be affected if the creation of the user profile were moved for efficiency sake. Thanks!

Hey NiKole,

You'll want to always keep your passwords hashed. There is no acceptable reason why a PM's preferences should take precendece to data security. As for UAT, the whole point of using an external lib — like bcrypt — is so that you don't have to do any testing of the hashing implementation; you can just assume that it works.

Thanks - but my question isn't do we hash or unhash, its regarding the order of operations for completing the profile setup piece.

I'm sure experiences vary across the board but when dealing with an Enterprise client, or one that's more high profile, a business and liability perspective, you wouldn't just leave that encryption as an assumed validation or rather I wouldn't.

Could you elaborate on what you mean by order of operations? If you're speaking generally, there are many software development paradigms that a development team could pick from regarding how to go about building an app.

So, there's risk in every decision you make as a product owner. Believe it or not, choosing to adopt a proven, throughly-tested, open-source library — as opposed to rolling your own — is the less riskier bet, by far.

Order of operations, time efficiency, work flow, project plan. Ordering the tasks so that they make sense in a logical fashion by yielding the most productivity of a resource.

Validating that your expected functionality is working does not mean remaking a wheel. Its no different than testing that your server is up and running. But again, that piece is not what my question was regarding, its the profile setup and its placement within the project.

The order of operations of a given software project depends on the requirements spec for that project, as well as the strengths and weaknesses of the team that's building it. There's no silver bullet here, just guidelines and heuristics, some that have been more successful than others. But, you seem to be thinking that real-world software projects have as straightforward a process as shown in this course — they don't. The software design & development process is iterative and fairly complex, a bit too complex to be summed up in a comment.

Regarding the validating of the library bit, the testing you're referring to is known as integration testing. And the thing with integration testing is you'll never be able to test every possible permutation of integrations between components of an app. This is why, in general, you'll want a whole lot of unit-tests (automated) and a few (automated, but could be manual) integration tests. In this app's case, the point I was making is that, it would make no sense to waste resources running integration tests on the hashing function of a library that's already been thoroughly unit-tested and had its tires kicked by an entire community of developers.

Mikis I've worked with Enterprise, Security and Implementation of software projects as a Business Process Developer for over 10 years. Yes, if I find a training that varies from my experience, it is logical to ask a question to help understand how to fit that in my go forward routine, so I can use what is learned at Treehouse and implement it in my own fashion for development of my own applications catering to the business community - which is a lot more stringent than other communities. This is what I understood the Community forum to be for, asking questions. I'm aware that all projects will vary however my question - wasn't meant to go down a rabbit hole about security and at this point I do regret mentioning it all. I wish it weren't pertinent to my actual question but it is.

Stated differently that question was whether or not as a Best Practice we should hold off on the creation of the profile as Dave did in the video. Was this done because it has to be that way or was it something done for the sake of teaching us an objective but can be adjusted going forward. I'll find the answer I am actually seeking from another resource.

Thanks for the vibrant morning of discussion.