Handle grpc authentication errors

[antgamdia]

Description of the change

As reported at #5295, the axios interceptor handling the logout does not work anymore (bc all the requests are handled by the grpc client).
This PR is to intercept the auth-related errors to force a programmatic logout.

Benefits

If an auth error happens, we will log the user out.

Possible drawbacks

Maybe we don't want to kick the user out in some points, but we can fine-tune it later.

Applicable issues

• fixes Handle authentication errors in grpc calls #5295

Additional information

Problem: I've found some grpc calls NOT returning the proper status code... this forced me to add some ugly workarounds looking for certain keywords to appear to detect a true auth error.

Demo:

WIP as there are still several test cases to fix

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	5469f1d
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/6317cc0e08c68d00080d144c

[castelblanque]

There is actions.auth.logoutByAuthenticationError() repeated in many places.
I was wondering if we could refactor that to be generic with something like e.g. (pseudo-code):

export function handledErrorAction(err: ActionType<any>, e: any){
  if (e.constructor === UnauthorizedError) {
    return actions.auth.logoutByAuthenticationError();
  } else {
     return err;
  }
}

So that invocations can be almost a one-liner like e.g.:

dispatch(
      handledErrorAction(errorInstalledPackage(new FetchError("Unable to list apps", [e])), e)
)

[antgamdia]

Good idea, thanks! Will do!
Also, I'd like to explore the grpc interceptors at some point. Don't know if they can fit our main goal here, though. https://grpc.io/blog/grpc-web-interceptor/

[castelblanque]

InvalidArgument does not look like an internal server error? Maybe an error like e.g. UnprocessableEntity fits better?

[antgamdia]

It is not, of course. This is tricky, as we aren't really actually using those error objects... so I just defaulted them to "server error" with no specific criteria.
Let's create error objects grouping some of them, as we may want to have them in the future. See what you think

[castelblanque]

Agree with creating error objects that extend CustomError so that we can have some groups.

[castelblanque]

A bit weak, but I guess it is the only thing we can do until all error codes from backend are harmonized.

[castelblanque]

LGTM, thanks!

[antgamdia]

To investigate: using goharbor.com chart repo+ credentials + kicks me out, verify which grpc code we are returning when adding repos.
Edit: it happens when the Helm validation returns the response code from the repo, in this case, 401. But we should shallow this 401 and return a proper code instead. 400-alike maybe?

[castelblanque]

Tested the case, and it is returning a GRPC status 9 (Failed precondition).

grpc-message: Unable to add package repository "asdasda" using the plugin "helm.packages": rpc error: code = FailedPrecondition desc = Failed repository validation: &{401 {"errors":[{"code":"UNAUTHORIZED","message":"UnAuthorized"}]}%0A}
grpc-status: 9

That wraps the HTTP 401 returned by Harbor, indeed.

Maybe we need to process the 401 error in the backend and map it correctly. If it is a 401 that Harbor sends, I would return a grpc status 7 (Permission denied) or 3 (Invalid argument).
However, the PERMISSION_DENIED status could be confused with the user not having permissions to perform the operation itself in Kubeapps APIs, which is not the case. We might want to return instead the grpc status 3 (Invalid argument) and specify a more readable message text.