You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
halkyon
changed the title
Gateway and Linksharing should throw 500 server errors if the auth bearer token is wrong
Gateway and Linksharing should throw 500 server errors and log if the auth bearer token is wrong
Sep 22, 2023
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
The text was updated successfully, but these errors were encountered: