globus api --scope-string (for clients)

[derek-globus]

What?

• The globus api <service> command now supports a --scope-string parameter.

  • If supplied, the CLI will enforce that any specified scope strings are included
    in consent requirements in addition to standard service scope requirements.

  • This parameter may be supplied multiple times to specify multiple scope strings.

  • This parameter is only supported in the context of Client Credentials-based authentication.
    (Client Credentials with GLOBUS_CLI_CLIENT_ID)

Why?

Provide users a path to interact with APIs not currently supported in the CLI which require specific scope consents (ie. auth's project management apis)

Testing

> export GLOBUS_CLI_CLIENT_ID="...redacted..."
> export GLOBUS_CLI_CLIENT_SECRET="...redacted..."
> globus api auth GET /v2/api/projects --scope-string 'urn:globus:auth:scope:auth.globus.org:manage_projects'

[kurtmckee]

Recommending removal of "for this command". I've rewrapped the lines as well.

Suggested change

	"A scope string to consent to for this command (only supported for "
	"confidential client usage). "
	"Pass this option multiple times to specify multiple scopes."
	"A scope string to consent to "
	"(only supported for confidential client usage). "
	"Pass this option multiple times to specify multiple scopes."

[derek-globus]

Is this based on the standup conversation yesterday around "we'll keep using this cached token which now has expanded consents"? Or is this more of just trying to make it read cleaner?

[kurtmckee]

Only about readability -- "to consent to for" caught my eye.

[sirosen]

One minor question/refactoring option, but I like how tightly this is scoped.
Because it passes through the existing login manager mechanisms, I have fewer concerns about impact, upon review, than I voiced in earlier discussions.