4 ms·

Absolutely this. The iOS mobile client of a system of I was responsible for once spontaneously stopped working, dumping users back to the login screen. The Andr

Absolutely this. The iOS mobile client of a system of I was responsible for once spontaneously stopped working, dumping users back to the login screen. The Android client was fine, and we couldn't see any issues in the backend logs. After quite a bit of digging into the problem we eventually found that the iOS app was using a single error handler for all HTTP requests, including the one being made to query Status Page for any active incidents so they could be shown to users - our Status Page account had been erroneously disabled, which meant the requests were returning a 401, which the app interpreted as the user needing to re-authenticate. I'm not sure I've ever been embarrassed than having to report upstream that the cause of an incident was our solution for flagging incidents to customers.

gwbas1c 4y ago
It's more common than you think. The Liftmaster MyQ app for my garage door openers does the same thing: Any kind of error and it knocks you back to the sign in screen.
chrismorgan 4y ago
> our Status Page account had been erroneously disabled, which meant the requests were returning a 401 Part of the bug here would seem to be this returning a 400-class status code: it should pretty obviously be a 500-. The most suitable standard code is 503 Service Unavailable.
- d_watt 4y ago
  If we're going to pedant about status codes, it seems like 401 is correct. 500 is a "server error" range, 503 would imply the service is down due to server side issues. 401:"not authorized" seems exactly correct for status page saying "I know who you are, and what you want, but you can't have it because you chose to disable your account."
  - chrismorgan 4y ago
    I am assuming account-specific endpoints, which on reflection isn’t guaranteed, but is I think reasonable to expect. On a shared endpoint, 401 would be reasonable, but on a dedicated endpoint I maintain it’s unreasonable and incorrect. 401 is only permitted if an Authorization header is missing or insufficient, and the server “MUST send a WWW-Authenticate header field containing at least one challenge applicable to the target resource” (https://www.rfc-editor.org/rfc/rfc9110#name-401-unauthorized https://www.rfc-editor.org/rfc/rfc9110#name-401-unauthorized). Presuming an account-specific status page endpoint, this cannot be satisfied; nothing the client can send will work, therefore it’s far more reasonably treated as a server error than a client error: the server has been instructed not to service these requests. “Service Unavailable” is clearly suitable. (Refusing the connection would also be reasonable, and have certain technical advantages for machine use.)

gwbas1c 4y ago

It's more common than you think. The Liftmaster MyQ app for my garage door openers does the same thing: Any kind of error and it knocks you back to the sign in screen.

chrismorgan 4y ago

> our Status Page account had been erroneously disabled, which meant the requests were returning a 401 Part of the bug here would seem to be this returning a 400-class status code: it should pretty obviously be a 500-. The most suitable standard code is 503 Service Unavailable.

d_watt 4y ago
If we're going to pedant about status codes, it seems like 401 is correct. 500 is a "server error" range, 503 would imply the service is down due to server side issues. 401:"not authorized" seems exactly correct for status page saying "I know who you are, and what you want, but you can't have it because you chose to disable your account."
- chrismorgan 4y ago
  I am assuming account-specific endpoints, which on reflection isn’t guaranteed, but is I think reasonable to expect. On a shared endpoint, 401 would be reasonable, but on a dedicated endpoint I maintain it’s unreasonable and incorrect. 401 is only permitted if an Authorization header is missing or insufficient, and the server “MUST send a WWW-Authenticate header field containing at least one challenge applicable to the target resource” (https://www.rfc-editor.org/rfc/rfc9110#name-401-unauthorized https://www.rfc-editor.org/rfc/rfc9110#name-401-unauthorized). Presuming an account-specific status page endpoint, this cannot be satisfied; nothing the client can send will work, therefore it’s far more reasonably treated as a server error than a client error: the server has been instructed not to service these requests. “Service Unavailable” is clearly suitable. (Refusing the connection would also be reasonable, and have certain technical advantages for machine use.)