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
I know the documentation for API key authentication says that one must set it up using persistent headers, but the interactive menus are misleading and guide the user towards a dead-end. Here's what I see when setting up a new API:
▶ restish api configure myexample
? Base URI https://api.example.com
Setting up a `default` profile
? Select option for profile `default`
> Add header
Add query param
Add custom base URL
Setup auth
Finished with profile
Here, I picked "Setup auth" (I hadn't read the docs yet), and was faced with the following prompt:
? API auth type [Use arrows to move, type to filter, ? for more help]
> http-basic
external-tool
oauth-client-credentials
oauth-authorization-code
No "API key" can be found here. At this point, I went to the docs, which say:
The following auth types are supported:
HTTP Basic Auth
API key
OAuth 2.0 client credentials
OAuth 2.0 authorization code
External Tool
Well, I can see four of those in the list, but not the one I'm looking for. Now I'm thinking this is either a bug in the program or something misconfigured in my end. I decided to check the issue tracker, and found #44, which mentions configuration using a header. I then read the docs more carefully and find this bit:
There is no explicit auth support for API keys because they are already handled by persistend headers or query parameters.
IMHO, both the docs (with the initial reference of support for API keys in the same list that includes other authentication types for which there's an explicit mechanism) and the CLI (which offers a "Setup auth" option with no indication that one actually needs to pick "Add header" instead in the case of API key auth) are misleading.
Of course, the simplest solution would be to edit the docs so the caveat appears earlier, and the entry in the list is demarcated from the others (e.g. using an asterisk or something). But I think the best way resolve this would be to add support for API key authentication in the "Setup auth" CLI menu, in a way that would transparently add the header as if one had picked "Add header". (The docs changes would still be worth doing, of course.)
The text was updated successfully, but these errors were encountered:
waldyrious
changed the title
API registration should make it easier to an API token
API registration should make it easier to set up API token auth
May 11, 2023
I know the documentation for API key authentication says that one must set it up using persistent headers, but the interactive menus are misleading and guide the user towards a dead-end. Here's what I see when setting up a new API:
Here, I picked "Setup auth" (I hadn't read the docs yet), and was faced with the following prompt:
No "API key" can be found here. At this point, I went to the docs, which say:
Well, I can see four of those in the list, but not the one I'm looking for. Now I'm thinking this is either a bug in the program or something misconfigured in my end. I decided to check the issue tracker, and found #44, which mentions configuration using a header. I then read the docs more carefully and find this bit:
IMHO, both the docs (with the initial reference of support for API keys in the same list that includes other authentication types for which there's an explicit mechanism) and the CLI (which offers a "Setup auth" option with no indication that one actually needs to pick "Add header" instead in the case of API key auth) are misleading.
Of course, the simplest solution would be to edit the docs so the caveat appears earlier, and the entry in the list is demarcated from the others (e.g. using an asterisk or something). But I think the best way resolve this would be to add support for API key authentication in the "Setup auth" CLI menu, in a way that would transparently add the header as if one had picked "Add header". (The docs changes would still be worth doing, of course.)
The text was updated successfully, but these errors were encountered: