1. Nested database transactions could exhaust the transaction pool and deadlock 2. Same as you described with doing eg HTTP during transactions

We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.

I think this is likely unnecessary for most use cases and is mostly a RAM saving measure, but could help in some cases.

* It's obvious from the schema: If there's a `deleted_at` column, I know how to query the table correctly (vs thinking rows aren't DELETEd, or knowing where to look in another table)

* One way to do things: Analytics queries, admin pages, it all can look at the same set of data, vs having separate handling for historical data.

* DELETEs are likely fairly rare by volume for many use cases

* I haven't found soft-deleted rows to be a big performance issue. Intuitively this should be true, since queries should be O log(N)

* Undoing is really easy, because all the relationships stay in place, vs data already being moved elsewhere (In practice, I haven't found much need for this kind of undo).

In most cases, I've really enjoyed going even further and making rows fully immutable, using a new row to handle updates. This makes it really easy to reference historical data.

If I was doing the logging approach described in the article, I'd use database triggers that keep a copy of every INSERT/UPDATE/DELETEd row in a duplicate table. This way it all stays in the same database—easy to query and replicate elsewhere.

Comments URL: https://news.ycombinator.com/item?id=43186078

Points: 6

# Comments: 1

We allow multiple security keys. You can add more here: https://app.mercury.com/settings/security

To be clear this is what we're trying to avoid. An easily typeable code like that can be typed into a phisher's website.

That said, our security team and I agree there is no security issue here. Mailgun already can see the text of the emails we send.

You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?

We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.

This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.

Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security

That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.

Lemme know if you have any questions!

Comments URL: https://news.ycombinator.com/item?id=41201651

Points: 3

# Comments: 1

Should this be “an” in the page header?

Comments URL: https://news.ycombinator.com/item?id=37711052

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37711046

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37710380

Points: 2

# Comments: 1

(I helped make such a product 7 years ago)