When setting up a new authservice cluster we noticed when switching over DNS that our uptime checks started returning 401 errors, and we started to think some records weren't correctly set up in the database.
The actual problem seemed to be that the authservice bearer token had changed, but it was still talking to the old server, as the DNS hadn't fully switched over yet. Authservice was throwing 401s, but authclient (the package used by both Gateway and Linksharing to talk to Authservice) doesn't differentiate between bearer token invalid, and user access key invalid as both respond with a 401 by authservice, so it misled into thinking we were missing some records.
One idea to fix this is to return a different status code, although technically 401 still makes sense for either case since you're not authorized. 403 only makes sense if you're authorized but don't have access to the resource.
Maybe if the error response included a message about the bearer token being wrong, then authclient can check that and raise this as 500 server error instead.
Acceptance Criteria
Setting the wrong authservice bearer token and sending a request to Gateway and Linksharing results in a 500 server error.
The Gateway and Linksharing logs show that the bearer token is wrong.
Goal
When setting up a new authservice cluster we noticed when switching over DNS that our uptime checks started returning 401 errors, and we started to think some records weren't correctly set up in the database.
The actual problem seemed to be that the authservice bearer token had changed, but it was still talking to the old server, as the DNS hadn't fully switched over yet. Authservice was throwing 401s, but authclient (the package used by both Gateway and Linksharing to talk to Authservice) doesn't differentiate between bearer token invalid, and user access key invalid as both respond with a 401 by authservice, so it misled into thinking we were missing some records.
One idea to fix this is to return a different status code, although technically 401 still makes sense for either case since you're not authorized. 403 only makes sense if you're authorized but don't have access to the resource.
Maybe if the error response included a message about the bearer token being wrong, then authclient can check that and raise this as 500 server error instead.
Acceptance Criteria