Hacker News Reader

Comment by taeric | Hacker News Reader

This sounds suspicious. They had other mechanics to guard against abuse than auth?

Worst case would be a renegade client that constantly used the open door, no?

I think this is a backend thing, so renegade client isn't an issue. The choice is: if the auth system was down, should the video system prevent everyone from seeing video, or let everyone in. If auth is down, some people will be able to watch when the shouldn't be able to, but only for the period of time while the auth system is down.

Wouldn't this only allow recently authenticated people in? That is, connections at this point can check if there is an "authenticated" flag set. Assuming any basic expiration, the only people getting through this are those that have recently lost authorization. They were still authenticated. Right?

If auth is up, everything works as normal. If it's down let everyone in.

I'm envisioning something on the backend equivalent to:

OnGetVideoChunkRequest: if Authorized(User) or IsDown(AuthSystem) then SendVideoChunk

Makes sense. Still surprises me that it wouldn't be a check more like "if not expiredOrAbsentAuthentication..."

I think you're overly focusing on details. Authorized(User) might check expiration or other things, but that isn't really relevant to the fail open vs fail close idea being discussed.

I'm focused on connections. All systems should not have to connect back to the auth system to do their job. To that end, determining that a connection is trusted is not a weak versus strong consistency issue.

Now, checking a password in the system should be strongly consistent. In that I should be able to update my password and immediately use the updated password. Any other behavior will surprise me.

I wouldn't take my example too literally. The example was just to illustrate the basic logic for fail open and intentionally wasn't complete or detailed.

For purposes of discussing fail open, how that logic gets translated during implementation doesn't matter. Authorized(User) might be expiring tokens passed in via cookie. IsDown(AuthSystem) could just check some global flag that gets set by some watchdog service on a AuthSystem heartbeat. It could be something else. It doesn't matter because it's not relevant.

Having a direct connection to the AuthSystem or not is an implementation detail, not something that changes the idea "Netflix should fail open".

I suspect it is just focusing on an example. So, to that, apologies if I am over diluting the conversation. Rereading my first post, I should have been clearer that I can agree with the point. Just don't know if auth is the domain I would pick, since it isn't a persisted thing, but a vouched one.

Similarly, anywhere you are doing idempotent guarantees, strong consistency is vital. Same for customer interaction. Reads following writes that a user made should almost certainly strive for strong consistency. If only to avoid confused customers.

Writes the system makes, though? Expect those to just fail in ways that will leave things inconsistent and constantly check for them.

It would only fail open if the connection from the auth service to the database was down. It's all server side.

See my sibling response. This doesn't sounds like a consistency debate as much as a trusted connections debate.

Reply on news.ycombinator.com