Previously we allowed access to the credentials store only indirectly
through the Disco object, and that's fine for callers that only need to
_read_ credentials, but more specialized callers like "terraform login"
and "terraform logout" need more information in order to be transparent
to the user about what they are going to do and where the credentials
are going to be stored.
A more convenient interface to get a throwaway empty credentials source
for use in tests, which doesn't interact at all with the real CLI
configuration directory.
A server is allowed to omit AuthorizationURL if it's using the "password"
grant type, and other future grant type implementations may have similar
accommodations.
* website/formatdate: update example
The given example was showing HOUR:MONTH instead of HOUR:MINUTE
Fixes#22598
* website/import: remove reference to no-longer-working option
Users can no longer supply `-config=""` to tell Terraform not to load
configuration for import.
Fixes#22294
* website/provisioners: `host` is required in connection blocks
Fixes#21877
* website/variables: clarify variable definition precedence
It was not entirely obvious that a variable could not be assigned
multiples times in a single source.
Fixes#21682
* website/backend/local: add `workspace_dir` attribute
Fixes#21391
* website/output: `sensitive` outputs are redacted in output
Fixes#21502
* website/backends: sidebar order tweak
It makes sense for backend 'configuration' to appear before 'init'.
Fixes#13796
* Revert "website/formatdate: update example"
This reverts commit ccd93c86ddd15a21625c0767702ee1cc62e77254.
Previously `terraform console` would output an `init required` error if
it was run in a directory originally `init`ed with a `-plugin-dir`
specified.
Fixes#17826
This should not cause any change in behavior yet, but using this new
implementation will allow the "terraform login" and "terraform logout"
commands to store and forget credentials when they are implemented in
subsequent commits.
This was a leftover from the migration of these types from the main
package, but we don't actually need or want this here because this
particular detail is still handled by the main package, and because the
cliconfig package must not depend on the command package in order to avoid
an import cycle.
This new implementation is not yet used, but should eventually replace the
technique of composing together various types from the svchost/auth
package, since our requirements are now complex enough that they're more
straightforward to express in direct code within a single type than as
a composition of the building blocks in the svchost/auth package.
This introduces two new verbs to the credentials helper protocol to store
and forget credentials, and uses them to implement StoreForHost and
ForgetForHost.
This new functionality will be used as part of implementing the
"terraform login" and "terraform logout" commands.
As of this commit, the storage codepaths are all just stubs. Subsequent
commits will implement these new methods for each of the different
physical credentials sources.
We'll use this to call the Windows ReplaceFile API for safe file
replacement when updating credentials.tf.json in "terraform login" and
"terraform logout".
Previously we just assumed support for the authorization code grant type,
but now we'll allow the host to declare which grant types it supports
to allow for more flexibility in host login implementations. We may extend
the set of supported grant types in future.
The OAuth specification requires several distinct arguments to be provided
to configure a client, rather than just a URL. To accommodate this, we'll
add a new method to the service discovery API to retrieve OAuth client
information in a Terraform-specific form. (The OAuth specification itself
considers this out of scope, because most OAuth clients are configured
by just hard-coding these settings into them for a particular remote
service.)
We can only validate MinItems >= 1 (equiv to "Required") during
decoding, as dynamic blocks each only decode as a single block. MaxItems
cannot be validated at all, also because of dynamic blocks, which may
have any number of blocks in the config.
Due to both the nature of dynamic blocks, and the need for resources to
sometimes communicate incomplete values, we cannot validate MinItems and
MaxItems in CoerceValue.
Martin Atkins