3 ms·

> Then you do the second API call to get the hometowns of the userIDs. The result contains the new place that you should not have been able to access This is a

• jlokier 7y ago
  Not really, that's just an artifact of the example, which I constructed to emphasise that consistency errors can be serious. But I agree that if access control were used (and pushed down to the database, rather than implemented on the client side), it would prevent that particular example from returning the disallowed data. Even with access control the problem is still there. In the example but with database-level access control added as you suggest, the client gets an access error instead of a consistent resultset. Or missing data instead of a consistent resultset. In either case, the client needs extra code to handle the inconsistency caused by the sequence of dependent HTTP requests, or it will render an invalid screen. In some cases, maybe throw errors trying to render it because the data is in an "impossible" state that wasn't allowed by the database logic. For example, a person without an address is shown, even though the database never contains a person without an address. Or nothing is shown, because of the access error, unless the client has "retry on access error" logic. Try to imagine how unprofessional that would look if it was, say, a bank statement line without an amount. These inconsistent data hazards can get complicated easily, as they arise from all sorts of weird corner cases that rarely arise and are hard to enumerate. Defensive programming is needed to handle them, and even then it can be hard to ensure every case is handled well. They are also hard to test.