Malformed can-i URL on non-kubeapps cluster

[antgamdia]

Description:

405 errors are thrown when hitting the can-i URL in the cluster in which Kubeapps in installed on, but without declaring it under the clusters: object in the values.yaml.
It results in a currentCluster == "", so when building the URL, the empty is passed through.

There is -no- UX impact, but it generates unexpected calls in Kubeops depending upon the browser.

1. performs a POST request to api/v1/clusters//can-i
2. got a 301 redirect to api/v1/clusters/can-i
3. browser (ignoring the RFC) changes the POST to a GET method
4. kubeops receives GET api/v1/clusters/can-i, returning a 405 method not allowed

Steps to reproduce the issue:

1. Configure Kubeapps so that users can target a second cluster and not target the cluster on which Kubeapps is installed,
2. Click on the AppRepositories menu item
3. See the network inspector

Describe the results you received:

405 status code response.

Describe the results you expected:

Either:

I) a 200 OK with authorized: no (since it using the serviceaccount, not the user account) (I'd go for this one)
ii) another meaningful and handled HTTP status code.

However, note that not generating a proper response for this case (requestedCluster=="") it will generate a 401 response, so users will get logged out each time they click on app-repositories.

Version of Helm, Kubeapps and Kubernetes:

devel Kubeapps

Originally posted by @antgamdia in #2712 (comment)