4 ms·

The problem with issues like this is that this is patch development. If you don't look a couple steps ahead and at least think through your "nice to have" prob

The problem with issues like this is that this is patch development. If you don't look a couple steps ahead and at least think through your "nice to have" problems, you might end up getting the architecture wrong. The password reset problem might drive you to find an authentication library instead of rolling your own. Suddenly, your "nice to have" problem is fixed before you get to it, because you decided to look at the larger picture instead of just rushing to just rely on an email and password column in your MVP. That way when you demo your app to an investor or early beta users, you won't be stuck saying "oh, there's no password reset, just create another one".

hinkley 6y ago
Definitely. People who think their problems are small or simple write their own libraries, and then every change in requirements gets incorporated into the library or blamed on the victim. By the time the system is profitable you've reimplemented half of a robust library, badly.
munificent 6y ago
This is a great point. It's important to be mindful of the path dependence you are creating for your future self. At any point in time, I think you can roughly bucket problems into three categories: 1. This is a blocking issue now. 2. This is not a block issue now, but postponing will cause more pain than we would save by not doing it now. 3. This is not a blocking issue and doesn't create future pain. The third bucket are natural to postpone. Finding the balance between the first two is one of the primary challenges of engineering.
- afarrell 6y ago
  I think there is a 4th category: This is not an obviously blocking issue right now, but it creates enough mental load that it prevents my work from being rewarding.
dakiol 6y ago
I'm curious, what's the right alternative to having an email and password columns in a "customers" table?
- john-shaffer 6y ago
  As one example, Django's auth framework gives you a users table which it manages. You would set a foreign key column from customers to users. I believe the point of GP was to say "use an auth framework". If you're rolling your own auth, then your approach is fine.
- twiss 6y ago
  In addition to the sibling answer of "use a framework"; if you simply stick passwords in a database, and the database gets stolen, you've now leaked your users' passwords. So you should hash the passwords, and they should be salted, so now you need a `salt` column. Most people use too cheap a hash function, so this is an additional argument for using a library / framework.
  - dakiol 6y ago
    Umm, but using bcrypt to hash the passwords is just a couple of lines of code (at least in Go); I'm wondering if I'm doing things wrong by not using a dedicated framework.
    - twiss 6y ago
      No, that's fine :) It wasn't clear to me from your original comment whether you were hashing passwords, apologies.
  - tonyarkles 6y ago
    As a minor nit, most salted password hash algorithms store the salt at the start (usually) or end (occasionally) of the hash, so you don't need a separate column. You end up with two functions: one to generate a new password hash (which securely generates a salt as well), and one to compare a plain-text password with the (salt+hash).
OJFord 6y ago
My instinct is to agree with you, but with my practical instinct-taming hat on, I reckon you could have between thousands and tens of thousands of monthly active users (depending on demographic - how likely they are to need reset) before taking a phone call to reset it manually in db would be burdensome. And between 0 and that many users you could have all sorts of other reasons for rethinking your authentication architecture, nevermind whether home grown or third-party library.

hinkley 6y ago

Definitely. People who think their problems are small or simple write their own libraries, and then every change in requirements gets incorporated into the library or blamed on the victim. By the time the system is profitable you've reimplemented half of a robust library, badly.

munificent 6y ago

This is a great point. It's important to be mindful of the path dependence you are creating for your future self. At any point in time, I think you can roughly bucket problems into three categories: 1. This is a blocking issue now. 2. This is not a block issue now, but postponing will cause more pain than we would save by not doing it now. 3. This is not a blocking issue and doesn't create future pain. The third bucket are natural to postpone. Finding the balance between the first two is one of the primary challenges of engineering.

afarrell 6y ago
I think there is a 4th category: This is not an obviously blocking issue right now, but it creates enough mental load that it prevents my work from being rewarding.

dakiol 6y ago

I'm curious, what's the right alternative to having an email and password columns in a "customers" table?

john-shaffer 6y ago
As one example, Django's auth framework gives you a users table which it manages. You would set a foreign key column from customers to users. I believe the point of GP was to say "use an auth framework". If you're rolling your own auth, then your approach is fine.
twiss 6y ago
In addition to the sibling answer of "use a framework"; if you simply stick passwords in a database, and the database gets stolen, you've now leaked your users' passwords. So you should hash the passwords, and they should be salted, so now you need a `salt` column. Most people use too cheap a hash function, so this is an additional argument for using a library / framework.
- dakiol 6y ago
  Umm, but using bcrypt to hash the passwords is just a couple of lines of code (at least in Go); I'm wondering if I'm doing things wrong by not using a dedicated framework.
  - twiss 6y ago
    No, that's fine :) It wasn't clear to me from your original comment whether you were hashing passwords, apologies.
- tonyarkles 6y ago
  As a minor nit, most salted password hash algorithms store the salt at the start (usually) or end (occasionally) of the hash, so you don't need a separate column. You end up with two functions: one to generate a new password hash (which securely generates a salt as well), and one to compare a plain-text password with the (salt+hash).

OJFord 6y ago

My instinct is to agree with you, but with my practical instinct-taming hat on, I reckon you could have between thousands and tens of thousands of monthly active users (depending on demographic - how likely they are to need reset) before taking a phone call to reset it manually in db would be burdensome. And between 0 and that many users you could have all sorts of other reasons for rethinking your authentication architecture, nevermind whether home grown or third-party library.