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
{{ message }}
This repository has been archived by the owner on Sep 21, 2020. It is now read-only.
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
The provider supports rules, rule configs, and hooks, but currently doesn't support hook secrets, which are the analog of configs for hooks.
A current workaround for this is simply to use templatefile with a hook resource. This is fully functional but somewhat less secure and requires the maintainer to store their hooks in files that are not necessarily valid JS, meaning for instance that they'll have issues with code analysis tools.
New or Affected Resource(s)
This would entail introducing a single new resource auth0_hook_secret. It's lifecycle callbacks would be implemented as follows:
Create: makes a call to this endpoint, with a single secret in the body, then sets the id of the resource
Read: makes a call to this endpoint (which gets all secrets for the hook) and then sets only the value for the desired secret
Update: makes a call to this endpoint, again with a single secret
Destroy: makes a call to this endpoint, passing an array containing only the name of the secret
Changes to the name field should force a new resource. This is equivalent to but simpler than correctly implementing name changes.
Also, there's a question about how to set the ID of a resource. Using {hook_id}{separator}{secret_name} has the advantage that it will be possible to do imports. However, since hook_id is itself an opaque string, choosing a separator is difficult. Moreover, imports seem unimportant for this resource since destroying and re-creating is generally low cost.
Community Note
Description
The provider supports rules, rule configs, and hooks, but currently doesn't support hook secrets, which are the analog of configs for hooks.
A current workaround for this is simply to use
templatefile
with a hook resource. This is fully functional but somewhat less secure and requires the maintainer to store their hooks in files that are not necessarily valid JS, meaning for instance that they'll have issues with code analysis tools.New or Affected Resource(s)
This would entail introducing a single new resource
auth0_hook_secret
. It's lifecycle callbacks would be implemented as follows:Changes to the
name
field should force a new resource. This is equivalent to but simpler than correctly implementing name changes.Also, there's a question about how to set the ID of a resource. Using
{hook_id}{separator}{secret_name}
has the advantage that it will be possible to do imports. However, sincehook_id
is itself an opaque string, choosing a separator is difficult. Moreover, imports seem unimportant for this resource since destroying and re-creating is generally low cost.Potential Terraform Configuration
The text was updated successfully, but these errors were encountered: