influx secret list returns misleading error message when user isn't authorized to view secrets

[tarainfluxd]

Steps to reproduce:
I have a configuration listed under influx config, and its organization exists / has been verified to exist in-browser.

1. influx secret list

Expected behavior:
Secrets to be listed.

Actual behavior:

Error: Organization not found.
See 'influx secret list -h' for help

Environment info:

• System info: Darwin 18.7.0 x86_64
• InfluxDB version: InfluxDB 2.0.1 (git: 37cc047) build_date: 2020-11-11T03:53:31Z

[docmerlin]

@tara-influxdata
I'm not able to reproduce this, can you try again with influx secret list --org "thename of your org"

[tarainfluxd]

@docmerlin

I tried again and get the same "Error: Organization not found." result.

[timhallinflux]

I can't reproduce this.

[tarainfluxd]

○ → influx  config ls
Active	Name		URL			Org
*	tara-config	http://localhost:8086	Taraness
	default		http://localhost:8086	<email address>

 2020-12-07 09:10:42 ⌚  tara-influxdata in ~
○ → influx secret list --org "Taraness"
Error: Organization not found.
See 'influx secret list -h' for help

[timhallinflux]

Still running 2.0.1? or can you repro on 2.0.2?

[tarainfluxd]

I can repro on 2.0.2.

[timhallinflux]

You must use an all access token in order to access the secrets. If you do not have an all access token -- you receive the organization not found error message.

[danxmoran]

@timhallinflux is the current behavior a bug? It looks we could at least improve the error message

[timhallinflux]

yes, error message needs improvement. It's not that the org isn't found it's that the user isn't authorized to make that API call, I believe.

[danxmoran]

This is trickier than I expected. The secrets API is never even being called in this case because:

1. The secrets API only accepts org IDs, not org names
2. Given an org name, the CLI first makes a request to the org API to get the matching ID
3. The org API rejects tokens that don't have org-level read access

IMO the ideal fix would be to extend the secrets API (and others) to accept either org ID or org name, so the server could provide relevant & specific error messages for these cases without compromising on auth for direct uses of the org APIs, but that would be a significant chunk of work & require coordination with cloud. In the short-term, I think we can add more context to the CLI-side error to make the source of the error more clear.