A business logic bug within auth.scala

[patseev]

Hey! Found a business logic bug within Auth algebra.

https://github.com/gvolpe/pfps-shopping-cart/blob/second-edition/modules/core/src/main/scala/shop/algebras/auth.scala#L68

Basically, users.find will return Some(User) only in case if caller has provided correct username & password. I suppose you need to introduce a different method that performs a search only via username.

Otherwise, given a username conflict it will go to None branch, then will attempt inserting a user with conflicting username and will raise a postgres-level exception instead of your custom one.

[gvolpe]

Hey @patseev , thanks for the report!

Looking at it now I would definitely model that function to perform a lookup just by username and compare the encrypted password afterwards. The way I see it, this is a design issue. I will consider it for the 2nd edition but I think we're a bit too late for the first one.

[gvolpe]

Oh @patseev, I think that is expected!

See https://github.com/gvolpe/pfps-shopping-cart/blob/second-edition/modules/core/src/main/scala/shop/algebras/users.scala#L30

The lookup is performed via username and the encrypted password is compared afterwards. That is in fact, how I would design it now, I guess that's some assurance 😄

Otherwise, given a username conflict it will go to None branch, then will attempt inserting a user with conflicting username and will raise a postgres-level exception instead of your custom one.

I'm afraid I don't understand this, what do you mean? A conflict can only happen if the same username already exists in the database.

[gvolpe]

Oh I get it now (sorry, Sunday after a few beers 😄 ) So yeah that's the validation for creating a new user you're talking about, definitely a case that wasn't tested. I'll get it fixed soon!