Coder Social home page Coder Social logo

alexkappa / terraform-provider-auth0 Goto Github PK

View Code? Open in Web Editor NEW
320.0 18.0 152.0 12.56 MB

ARCHIVED Auth0 Terraform Provider. This project is now being maintained at: https://github.com/auth0/terraform-provider-auth0

Home Page: https://registry.terraform.io/providers/auth0/auth0/latest/docs

License: Mozilla Public License 2.0

Go 96.17% HCL 2.56% Makefile 0.31% Shell 0.92% Dockerfile 0.04%
terraform terraform-provider auth0

terraform-provider-auth0's Introduction

THIS REPOSITORY HAS MOVED

This repository has moved into the Auth0 organization where it will be maintained at github.com/auth0/terraform-provider-auth0.

Auth0 Terraform Provider

Build Maintainability Test Coverage Gitter

Sponsors

If you would like to quickly implement a secure authentication flow with Terraform, create an Auth0 account; it's free!
If you or your company relies on this provider and would like to ensure its continuing support please consider sponsoring.

Usage

Terraform 0.13+

Terraform 0.13 and higher uses the Terraform Registry to download and install providers. To install this provider, copy and paste this code into your Terraform configuration. Then, run terraform init.

terraform {
  required_providers {
    auth0 = {
      source  = "alexkappa/auth0"
      version = "0.17.1"
    }
  }
}

provider "auth0" {}
$ terraform init

Terraform 0.12.x

For older versions of Terraform, binaries are available at the releases page. Download one that corresponds to your operating system / architecture, and move to the ~/.terraform.d/plugins/ directory. Finally, run terraform init.

provider "auth0" {}
$ terraform init

See the Auth0 Provider documentation for all the available resources.

Contributing

See CONTRIBUTING.md.

terraform-provider-auth0's People

Contributors

abulford avatar alexkappa avatar apamildner avatar cgriggs01 avatar cthos avatar edify42 avatar etwillbefine avatar hvassing avatar hypnoglow avatar jackton1 avatar jluiz20 avatar kevinschoonover avatar kgunbin avatar kpurdon avatar lpakula avatar mbelang avatar mcalster avatar mmindenhall avatar omar avatar politician avatar relu avatar rienafairefr avatar rkhoriander avatar sergiught avatar squarebracket avatar toshi1127 avatar willvedd avatar woz5999 avatar yinzara avatar yvovandoorn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-auth0's Issues

Provider crashes when custom domain is verified

The API doesn't return the verification field when the custom domain is verified.

[
  {
    "custom_domain_id": "123",
    "domain": "my_domain",
    "primary": true,
    "status": "ready",
    "type": "auth0_managed_certs"
  }
]

When the custom domain is verified, c.Verification.Methods doesn't exist and the provider crashes.
Affected line: https://github.com/yieldr/terraform-provider-auth0/blob/5cae09177f62e6c6d524f227ce19b51c1a8000e3/auth0/resource_auth0_custom_domain.go#L87

Error in TF:

panic: runtime error: invalid memory address or nil pointer dereference
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x181312a]
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: 
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: goroutine 42 [running]:
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/auth0.readCustomDomain(0xc000303500, 0x19980e0, 0xc000236a50, 0xc000303500, 0x0)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /go/src/github.com/yieldr/terraform-provider-auth0/auth0/resource_auth0_custom_domain.go:87 +0x21a
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Refresh(0xc0004295e0, 0xc000308500, 0x19980e0, 0xc000236a50, 0xc000391000, 0x10bd101, 0x187fc20)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:352 +0x160
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Refresh(0xc000429960, 0xc0003084b0, 0xc000308500, 0xc0002ca800, 0x18, 0x2601440)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:308 +0x92
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Refresh(0xc0004018a0, 0xc00043ae60, 0xc00043af30, 0x0, 0x0)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:549 +0x4e
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: reflect.Value.call(0xc00007b8c0, 0xc00000d7c0, 0x13, 0x1a0dffa, 0x4, 0xc000099f18, 0x3, 0x3, 0xc000304180, 0x0, ...)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /usr/local/go/src/reflect/value.go:447 +0x449
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0: reflect.Value.Call(0xc00007b8c0, 0xc00000d7c0, 0x13, 0xc000314718, 0x3, 0x3, 0x0, 0x0, 0x0)
2018-11-04T17:53:00.507Z [DEBUG] plugin.terraform-provider-auth0:       /usr/local/go/src/reflect/value.go:308 +0xa4
2018-11-04T17:53:00.508Z [DEBUG] plugin.terraform-provider-auth0: net/rpc.(*service).call(0xc000436680, 0xc0003edc70, 0xc000420b88, 0xc000420ba0, 0xc00010be00, 0xc000401900, 0x187fbe0, 0xc00043ae60, 0x16, 0x187fc20, ...)
2018-11-04T17:53:00.508Z [DEBUG] plugin.terraform-provider-auth0:       /usr/local/go/src/net/rpc/server.go:384 +0x14e
2018-11-04T17:53:00.508Z [DEBUG] plugin.terraform-provider-auth0: created by net/rpc.(*Server).ServeCodec
2018-11-04T17:53:00.508Z [DEBUG] plugin.terraform-provider-auth0:       /usr/local/go/src/net/rpc/server.go:481 +0x47e
2018/11/04 17:53:00 [ERROR] root: eval: *terraform.EvalRefresh, err: auth0_client.this: unexpected EOF
2018/11/04 17:53:00 [ERROR] root: eval: *terraform.EvalRefresh, err: auth0_custom_domain.this: unexpected EOF
2018/11/04 17:53:00 [ERROR] root: eval: *terraform.EvalSequence, err: auth0_client.this: unexpected EOF
2018/11/04 17:53:00 [ERROR] root: eval: *terraform.EvalSequence, err: auth0_custom_domain.this: unexpected EOF
2018/11/04 17:53:00 [TRACE] [walkRefresh] Exiting eval tree: auth0_custom_domain.this
2018/11/04 17:53:00 [TRACE] [walkRefresh] Exiting eval tree: auth0_client.this

I wish I knew more Golang to raise a PR. Sorry.

auth0_rule_config import unexpected "update in-place"

Community Note

  • 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

Terraform Version

Terraform v0.12.12
+ provider.auth0 v0.2.1

The issue is still prevalent with the most up-to-date setup as well:

Terraform v0.12.16
+ provider.auth0 v0.2.2

Affected Resource(s)

  • auth0_rule_config

Terraform Configuration Files

provider "auth0" {
  version       = "~> 0.2.1"
  domain        = "https://<domain>/api/v2/"
  client_id     = "<client_id>"
  client_secret = "<client_secret>"
}

resource "auth0_rule_config" "test" {
  key   = "TEST"
  value = "TEST"
}

Debug Output

terraform_import : https://gist.github.com/scottx611x/7153ac110a6c03078534a1b5509ab8c6
terraform_plan : https://gist.github.com/scottx611x/f7b5a9afaa557e4579d745dc00776f56

Panic Output

N/A

Expected Behavior

After a terraform import I would imagine a subsequent terraform plan to be a no-op assuming the provided auth0_rule_config value was identical to what exists in auth0

Actual Behavior

The subsequent terraform plan wants to update-in-place even when the locally set value and the value in auth0 match exactly.

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # auth0_rule_config.test will be updated in-place
  ~ resource "auth0_rule_config" "test" {
        id    = "TEST"
        key   = "TEST"
      + value = (sensitive value)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

  1. Create a rule config in auth0 (I went with key "TEST" value "TEST")
  2. Stub out an auth0_rule_config resource with the aforementioned key/value
  3. terraform import auth0_rule_config.test TEST
  4. terraform plan

Important Factoids

A terraform apply (with the update-in-place from above) produces a clean slate and subsequent plans are no-ops

References

N/A

Must import social provider before running TF

Community Note

  • 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

Terraform Version

Terraform v0.12.6

Affected Resource(s)

  • auth0_connection

Terraform Configuration Files

resource "auth0_connection" "google" {
  name     = "google-oauth2"
  strategy = "google-oauth2"
  options {
    client_id     = var.auth0_google_client_id
    client_secret = var.auth0_google_client_secret

  }
  enabled_clients = [
    auth0_client.my_client.id
  ]
}

Expected Behavior

Configure the google-oauth2 social connection.

Actual Behavior

Error that the connection already exists. Able to import the connection by finding the connection ID using the REST API.

It seems that all Social connections already exist, and before you can configure them with the auth0 provider you must import them into the state. After importing, they work correctly.

Is there a workaround to having to manually import into state?

Steps to Reproduce

  1. terraform apply

app_metadata, user_metadata not passed to auth0 correctly

Community Note

  • 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

Terraform Version

Terraform v0.11.14

Affected Resource(s)

  • auth0_user

Terraform Configuration Files

provider "auth0" {}

resource "auth0_user" "user" {
  connection_name = "Username-Password-Authentication"
  username = "test"
  user_id = "12345"
  email = "[email protected]"
  password = "passpass$12$12"
  nickname = "testnick"
  user_metadata = "{\"bar\":{\"baz\":\"qux\"},\"foo\":\"bar\"}"
  app_metadata  = "{\"bar\":{\"baz\":\"qux\"},\"foo\":\"bar\"}"
}

Expected Behavior

terraform state holds app_metadata and user_metadata and is in sync with actual state on auth0

Actual Behavior

terraform state holds app_metadata and user_metadata but is not in sync with auth0:

  • app_metadata, user_metadata is not passed to auth0
  • existing app_metadata, user_metadata on auth0 is ignored

Steps to Reproduce

  1. terraform apply
  2. Inspect actual configuration on auth0 (e.g. with web console, different API client)

Fix

this is fixed in https://github.com/tkeber/terraform-provider-auth0/tree/v0.2.0-metadata

multiple enabled_clients in a connection causes (un-needed) update

With a connection with multiple clients, a terraform plan/apply, with no changes, will be seen as having changed.

i.e. From a local test

~ module.dev-auth.auth0_connection.my_connection
enabled_clients.0: "C6Xzd6lSkJ4DeZaQtOFzGWbkpLdXbFY4" => "vegazNS4zcnGbIC7Vc70RzXrIbIWV1wM"
enabled_clients.2: "vegazNS4zcnGbIC7Vc70RzXrIbIWV1wM" => "C6Xzd6lSkJ4DeZaQtOFzGWbkpLdXbFY4"

It seems likely this is due to ordering (or the lack of) of the client list.

I might see if I can hack a solution shortly, (I'm no go/tf-plugin expert) so any guidance on where to look would be appreciated.

rule creation leads to enabled rule, always

Direct API call such as the following does the right thing:

curl -X POST \
  "https://$TENANT.auth0.com/api/v2/rules" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "name":    "rule-test",
    "script":  "exports.rule = function (user, context, callback) {\n  console.log({\n    user: user,\n    context: context\n  })\n  return callback(null, user, context);\n}\n",
    "enabled": false
}'

However using this terraform provider does not:

resource "auth0_rule" "terraform-test" {
  name    = "terraform-test"
  script  = "${file("${path.module}/rules/terraform-test.js")}"
  enabled = false
}
โฏ terraform apply
REDACTED OUTPUT

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + module.auth0-infra.auth0_rule.terraform-test
      id:      <computed>
      enabled: "false"
      name:    "terraform-test"
      order:   <computed>
      script:  "exports.rule = function (user, context, callback) {\n  console.log({\n    user: user,\n    context: context\n  })\n  return callback(null, user, context);\n}\n"


Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.auth0-infra.auth0_rule.terraform-test: Creating...
  enabled: "" => "false"
  name:    "" => "terraform-test"
  order:   "" => "<computed>"
  script:  "" => "exports.rule = function (user, context, callback) {\n  console.log({\n    user: user,\n    context: context\n  })\n  return callback(null, user, context);\n}\n"
module.auth0-infra.auth0_rule.terraform-test: Creation complete after 1s (ID: REDACTED)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.


โฏ terraform apply
REDACTED OUTPUT

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ module.auth0-infra.auth0_rule.terraform-test
      enabled: "true" => "false"


Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

The immediate second apply is demonstrates the bug.

I would love to see the raw underlying http request being sent by this provider but it being https traffic I didn't find a trivial way to sniff it (ngrep, tcpdump, etc.).

grant scopes empty array sent as null leading to 400 response

resource "auth0_client_grant" "telephone_client_grant" {
  client_id = "${auth0_client.telephone.id}"
  audience  = "${auth0_resource_server.dialogue_api.identifier}"
  scope     = []
}
Error: Error applying plan:

1 error(s) occurred:

* module.auth0-infra.auth0_client_grant.telephone_client_grant: 1 error(s) occurred:

* auth0_client_grant.telephone_client_grant: 400 Bad Request: Payload validation error: 'Expected type array but found type null' on property scope.

It seems that the changes in go-auth0/auth0#29 were not enough ๐Ÿค”

404 Errors when updating auth0_email_template

Community Note

  • 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

Terraform Version

v0.11.13

Affected Resource(s)

  • auth0_email_template

Terraform Configuration Files

provider "auth0" {
  domain        = "${var.auth0_domain}"
  client_id     = "${var.auth0_client_id}"
  client_secret = "${var.auth0_client_secret}"
  version       = "~> 0.1.18"
}

variable "auth0_from_email_address" {
  type = "string"
}

resource "auth0_email_template" "verify_email" {
  template                = "verify_email"
  body                    = "${file("./build/verify_email.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Please verify your email address"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 432000
  enabled                 = true
}

resource "auth0_email_template" "welcome_email" {
  template                = "welcome_email"
  body                    = "${file("./build/welcome_email.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Welcome to New Company!"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 0
  enabled                 = true
}

resource "auth0_email_template" "blocked_account" {
  template                = "blocked_account"
  body                    = "${file("./build/blocked_account.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Your New Company account has been blocked"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 432000
  enabled                 = true
}

resource "auth0_email_template" "stolen_credentials" {
  template                = "stolen_credentials"
  body                    = "${file("./build/stolen_credentials.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Your account credentials have been stolen"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 0
  enabled                 = true
}

resource "auth0_email_template" "enrollment_email" {
  template                = "enrollment_email"
  body                    = "${file("./build/enrollment_email.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Enroll in New Company MFA"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 0
  enabled                 = true
}

resource "auth0_email_template" "reset_email" {
  template                = "reset_email"
  body                    = "${file("./build/reset_email.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Change your New Company password"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 432000
  enabled                 = true
}

resource "auth0_email_template" "mfa_oob_code" {
  template                = "mfa_oob_code"
  body                    = "${file("./build/mfa_oob_code.html")}"
  from                    = "${var.auth0_from_email_address}"
  subject                 = "Your New Company MFA code"
  result_url              = ""
  syntax                  = "liquid"
  url_lifetime_in_seconds = 0
  enabled                 = true
}

Debug Output

Gist containing the output of tf plan (which succeeds) and tf apply (which fails)
https://gist.github.com/kevinohara80/a717f67f3c49ba2ffbb2da9b53bc24ed

Expected Behavior

auth0_email_template resource should update upon running terraform apply.

Actual Behavior

auth0_email_template resource are able to be created when running terraform apply for the first time. One the second tf apply, 404 error messages are returned.

Steps to Reproduce

  1. terraform apply to create the initial email template
  2. Make a change to the resource. Example: change the subject
  3. Run terraform apply again to attempt to update

Disabling google-auth2

google-auth2 is enabled by default with each new client.
I tried to read the code, but I can't seem to find any way to force not creating the connection.

Is there any known workaround to not have google-auth2 as part of every client?

Problem with creating client

Hi,

I am using the latest v0.1.12, and I am having an issue creating an Auth0 Client Application, here is my stanza:

resource "auth0_client" "application" {
  name            = "My Blog"
  description     = "My Blog"
  app_type        = "regular_web"
  is_first_party  = true
  oidc_conformant = true
  callbacks       = ["https://${aws_route53_record.main.fqdn}/oauth2/idpresponse"]
  allowed_origins = ["https://${aws_route53_record.main.fqdn}"]
  web_origins     = ["https://${aws_route53_record.main.fqdn}"]
  grant_types     = ["authorization_code", "implicit", "refresh_token"]

  custom_login_page_on = true
}

And here is the stack trace:

2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: panic: runtime error: invalid memory address or nil pointer dereference
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: [signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x1808f51]
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: goroutine 10 [running]:
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management.(*Management).request(0xc000394210, 0x1a18111, 0x4, 0xc000400000, 0x141, 0x1900200, 0xc0003f8000, 0x0, 0x0)
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management/management.go:136 +0xd1
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management.(*Management).post(0xc000394210, 0xc000400000, 0x141, 0x1900200, 0xc0003f8000, 0x141, 0xc00009c9c8)
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management/management.go:172 +0x68
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management.(*ClientManager).Create(0xc00032a4b8, 0xc0003f8000, 0x17bb1ac, 0xc0002c6f20)
2019-01-18T13:59:04.334Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/yieldr/go-auth0/management/client.go:114 +0xa1
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/auth0.createClient(0xc0003b2380, 0x19a1f40, 0xc000394210, 0x24, 0x228dce0)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/auth0/resource_auth0_client.go:447 +0x5f
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Apply(0xc000354a80, 0xc0000ad4a0, 0xc0002c6f20, 0x19a1f40, 0xc000394210, 0x100b601, 0xc00009cb80, 0x10bd81c)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:225 +0x351
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Apply(0xc000355110, 0xc0000ad450, 0xc0000ad4a0, 0xc0002c6f20, 0xc000088000, 0x18, 0x2600000)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:283 +0x9c
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Apply(0xc000132560, 0xc0002c6b00, 0xc0003b7740, 0x0, 0x0)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:527 +0x57
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: reflect.Value.call(0xc00031c600, 0xc00032a080, 0x13, 0x1a17ffd, 0x4, 0xc00009cf18, 0x3, 0x3, 0xc0000460c0, 0x0, ...)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/usr/local/go/src/reflect/value.go:447 +0x454
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: reflect.Value.Call(0xc00031c600, 0xc00032a080, 0x13, 0xc00006af18, 0x3, 0x3, 0x0, 0x0, 0x0)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/usr/local/go/src/reflect/value.go:308 +0xa4
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: net/rpc.(*service).call(0xc000300280, 0xc000328140, 0xc0003021f0, 0xc000302200, 0xc00034c200, 0xc000324a20, 0x1889040, 0xc0002c6b00, 0x16, 0x1889080, ...)
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/usr/local/go/src/net/rpc/server.go:384 +0x14e
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: created by net/rpc.(*Server).ServeCodec
2019-01-18T13:59:04.335Z [DEBUG] plugin.terraform-provider-auth0_v0.1.12: 	/usr/local/go/src/net/rpc/server.go:481 +0x47e

Could you please help?

options.password_history not able to be set

Hi, could very well be a case of user error here as new to TF.

Getting an error with the following

resource "auth0_connection" "db_user_connection" {
  name = "customers"
  strategy = "auth0"
  options = {
    password_policy = "fair",
    password_history = {
      enabled = true
    }
  }
}

This is returning me the following error:

auth0_connection.db_user_connection: 400 Bad Request: Payload validation error: 'Additional properties not allowed: enabled' on property options.password_history (Options for password history policy).

Hope someone can help
Regards

Connection created but "options" are not in request

Below is my terraform. Options doesn't seem to present in the request

resource "auth0_connection" "my_connection" {
  name = "HL0"
  strategy = "auth0"
  options = {
    password_policy = "excellent"
    enabled_database_customization = true
  }
}

From Auth0 log, the body section doesn't have options

...
"body": {
    "strategy": "auth0",
    "name": "HL0"
}
...

Enrich "options.validation" for Auth0 connection.

As Auth0 documentation states, there is a "options.validation" (defined
as an object), that can be applied to a Connection. Sadly, there are no specific documented
properties for that.

The use case and the problem

I want to set username min and max length for Auth0 database
connection - that options are available to configure through Auth0 UI.

To configure them through the Management API, I need to send the following json structure:

...
"options": {
    "validation": {
        "username": {
            "min": 2,
            "max": 10,
        }
    }

This works, and I also receive the same structure in the connection object
from the API for the "GET connection" request.

So, connection definition in terraform should look like this:

resource "auth0_connection" "default" {
  name     = "My-Database"
  strategy = "auth0"

  options = {
    requires_username = true

    validation = {
      username = {
        min = 5
        max = 15
      }
    }
  }
}

Currently, this does not work, because in the provider "validation" schema is defined as the following:

"validation": {
    Type:     schema.TypeMap,
    Elem:     &schema.Schema{Type: schema.TypeString},
    Optional: true,
},

So terraform wouldn't accept the auth0_connection definition above.

Another bad thing: if create a connection from terraform, then manually set
those validation properties on that connection through the UI, and then apply
the terraform again - they'll reset to default values.

BTW, I think this is related to #40 (same kind of issue)

Payload validation error: 'Too few properties defined (0), minimum 1' when creating client grant

With the following resource definition:

resource "auth0_client_grant" "test_client_grant" {
  client_id = "${auth0_client.test_client.id}"
  audience  = "${auth0_resource_server.ahana_api.identifier}"

  scope = [
    "file:upload",
    "file:download",
    "medicalHome:update",
  ]
}

I am getting the following error:

Error: Error applying plan:

1 error(s) occurred:

* auth0_client_grant.test_client_grant: 1 error(s) occurred:

* auth0_client_grant.test_client_grant: 400 Bad Request: Payload validation error: 'Too few properties defined (0), minimum 1'.

but there's not really any clear way to debug this... any pointers?

Missing ability to set many of the options for the github connection

Community Note

  • 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

Terraform Version

Terraform v0.12.17
Auth0 plugin v0.2.2

Affected Resource(s)

  • auth0_connection

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp

resource "auth0_connection" "github" {
  name     = "github"
  strategy = "github"

    options {
     // Doesn't seem to be support for setting these in the auth0 provider
     //
      email = true
      read_org = true
      profile = true
      read_user = true
      scope = [
        "user:email",
        "read:org",
        "read:user"
      ]
    }
}

Expected Behavior

It sets the options

Actual Behavior

Error: Unsupported argument

  on auth0.tf line 110, in resource "auth0_connection" "github":
 110:       email = true

An argument named "email" is not expected here.


Error: Unsupported argument

  on auth0.tf line 111, in resource "auth0_connection" "github":
 111:       read_org = true

An argument named "read_org" is not expected here.


Error: Unsupported argument

  on auth0.tf line 112, in resource "auth0_connection" "github":
 112:       profile = true

An argument named "profile" is not expected here.


Error: Unsupported argument

  on auth0.tf line 113, in resource "auth0_connection" "github":
 113:       read_user = true

An argument named "read_user" is not expected here.


Error: Unsupported argument

  on auth0.tf line 114, in resource "auth0_connection" "github":
 114:       scope = [

An argument named "scope" is not expected here.

Terraform exited with non-zero exit code: 1

Steps to Reproduce

  1. terraform apply

Important Factoids

If I fetch the connection using the REST api, I see the full set of options that I should be able to set:

{
  "id": "REDACTED",
  "options": {
    "client_id": "REDACTED",
    "client_secret": "REDACTED",
    "email": true,
    "read_org": true,
    "profile": true,
    "read_user": true,
    "follow": false,
    "public_repo": false,
    "repo": false,
    "repo_deployment": false,
    "repo_status": false,
    "delete_repo": false,
    "notifications": false,
    "gist": false,
    "read_repo_hook": false,
    "write_repo_hook": false,
    "admin_repo_hook": false,
    "write_org": false,
    "admin_org": false,
    "read_public_key": false,
    "write_public_key": false,
    "admin_public_key": false,
    "scope": [
      "user:email",
      "read:org",
      "read:user"
    ]
  },
  "strategy": "github",
  "name": "github",
  "is_domain_connection": false,
  "enabled_clients": [],
  "realms": [
    "github"
  ]

I also tried shoving them into the configuration hash within options, but while terraform was able to execute it, it didn't affect the matching settings on the connection resource in auth0, so I'm guessing thats not what it is for.

Support for passwordless connection email template

Community Note

  • 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

Normally, you can provide an email template via the email template endpoint. However, for some reason you can't set an email template for passwordless.

In order to setup a custom email for passwordless, you need to use the connections endpoint (I don't see this documented anywhere, but that's how it's done when using the dashboard > connections > passwordless > email).

New or Affected Resource(s)

  • auth0_connection

Potential Terraform Configuration

resource "auth0_connection" "passwordless" {
  name = "Passwordless-Connection"
  strategy = "email"
  options {
    ...
    email {
      body = "..."
      from = "{{ application.name }} <[email protected]>"
      subject = "Welcome to {{ application.name }}"
      syntax = "liquid"
    }
    ...
  }
}

Format CHANGELOG to conform to the terraform provider developer program

In order to participate in the terraform provider developer program, each Terraform provider must have a CHANGELOG that is updated during reach release. Since the changelog is updated by a bot during the release it must be in a certain format. With the AWS provider changelog as an example, the version of the nexte release should be tagged as โ€œ(Unreleased)โ€ and will then be updated with a date by the release-bot.

Salesforce community base url not updating

Hey @alexkappa - Sorry but I made a mistake in my last PR and didn't include the code to update the buildConnection function.

Community Note

  • 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

Terraform Version

Terraform v0.11.14

Affected Resource(s)

  • auth0_connection

Terraform Configuration Files

resource "auth0_connection" "salesforce_community_connection" {
  name                 = "salesforce-community"
  strategy             = "salesforce-community"
  is_domain_connection = false

  options = {
    client_id           = "${var.salesforce_client_id}"
    client_secret       = "${var.salesforce_client_secret}"
    community_base_url  = "https://www.example.com"
  }
}

Expected Behavior

Should have updated the config with the community_base_url of 'https://www.example.com'

Actual Behavior

The terraform state file was updated but the configuration itself was not.

Steps to Reproduce

Try this yourself with the above HCL file

  1. terraform apply

Important Factoids

References

Relates to a fix in issue #129 . The option is now supported, but doesn't activate the configuration

Terraform Provider Development Program - Initial Review

Hey Team, ๐Ÿ‘‹ My name is Chris, I'm a member of the Partner team @ HashiCorp.

Iโ€™ve taken a look at the provider here and would like to say great work so far! I do have feedback outlined below that Iโ€™d like to see addressed before we move on to the next steps. Iโ€™m opening this issues as a sort of checklist for tracking items and discussion. The review was done on the master branch at git commit 10ab4b3

  • All the acceptance tests are passing except for the CustomDomain test. It just appears to be failing due to that fact that this is a free tier test account. Is this the case or should all tests be passing?

  • Each Terraform provider must have its own terraform.io website documentation that should reside under a website/ directory. There should be a page for each resource and data source as well as an index page for the provider. Along with with must be a ruby layout file to represent the side bar directory.

  • There are a number of files that must be added in order for the provider to function in the Terraform native ecosystem.

    • The GNUmakefile is pretty standard across all Terraform providers, feel free to copy the NULL provider makefile, you will just have to update the variable on line 4 to PKG_NAME=auth0 and update to use โ€˜depโ€™
    • There are four bash scripts in a scripts/ that are used in different processes of testing and release, these can all be copied from the NULL provider
    • Each Terraform provider must have a CHANGELOG that is updated during reach release. Since the changeling is updated by a bot during the release it must be in a certain format. With the AWS provider changelog as an example, the version of the nexted release should be tagged as โ€œ(Unreleased)โ€ and will then be updated with a date by the release-bot.
    • All providers in the terraform-providers/ GitHub org have a TravisCI check run on each PR that is opened. Can you please update your .travis.yaml file to make the standard configuration
  • You currently have a MIT License on the provider, would you be able to change that to a MPL2 which is the standard across all Terraform providers.

Let me know if you have any questions.
-Chris

State is modified on update of user resource despite receiving a 400 from the API.

Community Note

  • 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

Terraform Version

terraform12 version
Terraform v0.12.6

  • provider.auth0 (unversioned)

Not sure why it says unversioned. Built from master.

Affected Resource(s)

  • auth0_user

Terraform Configuration Files

resource "auth0_user" "user" {
  connection_name = "Username-Password-Authentication"
  nickname = "rsatesting"
  email = "[email protected]"
  email_verified = true
  password = "<password>"
  app_metadata = "{\"groups\": [\"project:platform-admin\", \"foo:bar\"]}"
}

Debug Output

https://gist.github.com/rsalmond/48c98eb8790bf68a08804e8372b9f5b3

Expected Behavior

After receiving an error from the Auth0 API the local state should not have been modified.

Actual Behavior

Local state matches what is in the HCL, but not what is in Auth0.

Steps to Reproduce

  1. terraform apply the above HCL which succeeds.
  2. terraform state show auth0_user.user view the state and note the presence of the foobar group in the app metadata.
  3. Modify the HCL removing the foobar group @ sign from the user email address.
  4. terraform apply the updated HCL.
  5. Assuming it fails check the state again and note the foobar claim is gone.

Important Factoids

I suspect the root cause of the 400 error I'm seeing in my environment is an Auth0 rule run amok. You may have to adjust your request to force another type of failure, but I believe the state modification in the face of an error to be reproducible without the rules we have in place.

Terraform 0.12 support

Community Note

  • 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

Terraform 0.12 support.
Per here:

We have updated the provider SDK to support both the old and new protocols at once, to allow upgrading to newer provider versions while remaining on Terraform v0.11.

New or Affected Resource(s)

N/A

Potential Terraform Configuration

N/A

References

N/A

samlp addon configuration is not valid

When using the samlp addon configuration block, the generated configuration uses attribute names as defined on the schema. However, the actually configuration JSON uses camelcase for the attributes.

For example setting name_identifier_probes generates a config like:

{
  ...
  "name_identifier_probes": [ ... ]
  ...
}

If setup through the web UI it would instead use nameIdentifierProbes.

The samlp addon does not seem to understand this: using the debug feature on Auth0 it seems that it ignores them and instead uses defaults.

error on identifier update for all respective grants

Changing the identifier e.g.:

resource "auth0_resource_server" "dialogue_api" {
  identifier                                      = "${local.dialogue_api_audience}"

plan, e.g.:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ module.auth0-infra.auth0_client_grant.auth0_rules_grant
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.danvers_dialogue_grants
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.hippocrates_dialogue_grants
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.mano_client_grant
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.merck_dialogue_grant
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.push_notification_dialogue_grant
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_client_grant.usher_service_grant
      audience:   "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"

  ~ module.auth0-infra.auth0_resource_server.dialogue_api
      identifier: "https://api.dialoguecorp.com" => "https://api.dev.dialoguecorp.com"


Plan: 0 to add, 8 to change, 0 to destroy.
apply, fails for all grants (7), e.g.:
Error: Error applying plan:

7 error(s) occurred:

* module.auth0-infra.auth0_client_grant.auth0_rules_grant: auth0_client_grant.auth0_rules_grant: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.auth0_rules_grant
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.usher_service_grant: auth0_client_grant.usher_service_grant: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.usher_service_grant
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.merck_dialogue_grant: auth0_client_grant.merck_dialogue_grant: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.merck_dialogue_grant
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.push_notification_dialogue_grant: auth0_client_grant.push_notification_dialogue_grant: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.push_notification_dialogue_grant
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.mano_client_grant: auth0_client_grant.mano_client_grant: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.mano_client_grant
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.danvers_dialogue_grants: auth0_client_grant.danvers_dialogue_grants: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.danvers_dialogue_grants
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

* module.auth0-infra.auth0_client_grant.hippocrates_dialogue_grants: auth0_client_grant.hippocrates_dialogue_grants: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.11.11
    Resource ID: auth0_client_grant.hippocrates_dialogue_grants
    Mismatch reason: attribute mismatch: audience
    Diff One (usually from plan): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"audience":*terraform.ResourceAttrDiff{Old:"https://api.dialoguecorp.com", New:"https://api.dev.dialoguecorp.com", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}
    Diff Two (usually from apply): *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.


Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Missing option in salesforce-community connection

Community Note

  • 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

Hey @alexkappa :) We used your terraform provider and it was great. We found though it was missing this option for the salesforce-community connection.

PR to follow with this added in.

New or Affected Resource(s)

  • auth0_connection

Potential Terraform Configuration

We'd like to do this:

resource "auth0_connection" "salesforce_community_connection" {
  name                 = "salesforce-community"
  strategy             = "salesforce-community"
  is_domain_connection = false

  options = {
    client_id           = "${var.salesforce_client_id}"
    client_secret       = "${var.salesforce_client_secret}"
    community_base_url  = "${var.salesforce_community_base_url}"
  }

  enabled_clients = [
    "${auth0_client.spa_client.client_id}",
  ]
}

Unable to use `addons` when creating client.

I'm attempting to create a client (application) with the samlp addon configured. I can't seem to get the right syntax.

resource "auth0_client" "client" {
  name = "some-name"
  ...
  addons = {
    samlp = {
      audience = "audience"
      ... other nested maps here ....
   }
  }
}

Running terraform plan results in the error:

Error: module.auth0_sso_tools.auth0_client.client: addons.0 (samlp): '' expected type 'string', got unconvertible type '[]map[string]interface {}'

So I changed my declaration to:

resource "auth0_client" "client" {
  name = "some-name"
  ...
  addons = {
    samlp = <<EOF 
{
      "audience": "audience"
      ... other JSON properties here ....
}
EOF
  }
}

With this change I can now run terraform plan successfully, but when I run terraform apply I now get an error from the Auth0 API:

* auth0_client.aws_sso: 400 Bad Request: Payload validation error: 'Expected type object but found type string' on property addons.samlp.

So it would appear that the provider wants the addon configuration expressed as a string but it needs to be parsed to a JSON object before being sent to the API.

Am I missing something? Is there a syntax that can work for this?

`terraform refresh` fails with 404 when an Auth0 resource was destroyed manually

terraform refresh fails with 404 when some of the managed auth0 resources have been manually destroyed. apply and destroy commands will also fail due to the same reason and the only way to recover is to manually remove the affected resources from the state.
Other providers deal with such issues by silently removing the resources which are no longer present from the state during refresh.

Example:

$  terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + auth0_resource_server.my_resource_server
      id:                                              <computed>
      allow_offline_access:                            "true"
      identifier:                                      "https://api.example.com"
      name:                                            "Example Resource Server (Managed by Terraform)"
      scopes.#:                                        "2"
      scopes.0.description:                            "Create foos"
      scopes.0.value:                                  "create:foo"
      scopes.1.description:                            "Create bars"
      scopes.1.value:                                  "create:bar"
      signing_alg:                                     "RS256"
      skip_consent_for_verifiable_first_party_clients: "true"
      token_lifetime:                                  "8600"


Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

auth0_resource_server.my_resource_server: Creating...
  allow_offline_access:                            "" => "true"
  identifier:                                      "" => "https://api.example.com"
  name:                                            "" => "Example Resource Server (Managed by Terraform)"
  scopes.#:                                        "0" => "2"
  scopes.0.description:                            "" => "Create foos"
  scopes.0.value:                                  "" => "create:foo"
  scopes.1.description:                            "" => "Create bars"
  scopes.1.value:                                  "" => "create:bar"
  signing_alg:                                     "" => "RS256"
  skip_consent_for_verifiable_first_party_clients: "" => "true"
  token_lifetime:                                  "" => "8600"
auth0_resource_server.my_resource_server: Creation complete after 0s (ID: 5c644c21c96fc41a99e3912c)

Destroy the "Example Resource Server (Managed by Terraform)" manually via the Auth0 UI

$ terraform refresh
auth0_resource_server.my_resource_server: Refreshing state... (ID: 5c644c21c96fc41a99e3912c)

Error: Error refreshing state: 1 error(s) occurred:

* auth0_resource_server.my_resource_server: 1 error(s) occurred:

* auth0_resource_server.my_resource_server: auth0_resource_server.my_resource_server: 404 Not Found: The resource server does not exist

[bug] Realm and Options handling for ad strategy connections

Possibly two separate issues here, let me know if you want me to split. Only had an hour this morning to start troubleshooting, but just wanted to get something up to show where I was at with it.

  1. Realms: AD connection strategies are a bit odd in the auth0 API; they have an implicit realm named after the connection, but you cannot set this or modify it. It seems in the current version on master, attempting to use a previously working configuration for 0.1.0, that omits a realm, now breaks, resulting in 400 Bad Request: Realms is only supported for database connections.

  2. Options. This issue was previously existing. The only way to create an ad strategy connection was to not set options at creation time, and then set it to an empty map afterwards.

Example in terraform code (works first time, dirty/failing plan after).

 resource "auth0_connection" "my_ad_connection" {
	name = "Acceptance-Test-Ad-Connection"
	strategy = "ad"
}

#29 illustrates the current behaviour

Expose Client secret (in a safe way)

The AWS provider has the ability to expose access secret keys encrypted with PGP. This makes it possible to manage things without having to connect to AWS to get hold of secrets.

It would be useful to be able to do the same with Auth0 Clients - exposing the client secret in an encrypted way, such that terraform users can then decrypt the keys and put them in an appropriate place.

[BUG]: ResourceServer sends `identifier` on Update

When you try to update a resource server, you get the error:

* auth0_resource_server.xyz: 400 Bad Request: Payload validation error: 'Additional properties not allowed: identifier'.

This is because identifier is a read-only property of a resource server. Thus, it should not be sent along the the Management API on updates.

New release >v0.2.0

Hi @alexkappa

Any chance you can build and publish a new release? I'm guessing the CI isn't in a running state to publish the release automatically after merges to master?

Support for Credentials Per Workspace

We use several different environments for our infrastructure, and we use terraform workspaces to separate environment context. It would be great to be able to switch auth0 credential sets according to the terraform workspace that we're in, much like we can do with the AWS provider. Right now we have to run a wrapper shell script around terraform because we need to set the environment variables accordingly for each workspace, and we want to avoid hard-coding secret key into our codebase.

Add support for hooks

Looks like we have support for rules; hopefully adding support for hooks would be similar and could be implemented.

auth0_client client_metadata causes terraform crash

resource "auth0_client" "scheduling_app" {
  name            = "Scheduling App"
  description     = "An OIDC compliant authorization client for the scheduling backend .. Backend security (Managed by Terraform)"
  app_type        = "spa"
  is_first_party  = true
  oidc_conformant = true
  callbacks       = ["${var.application_base_url}${var.callback_endpoint}"]
  allowed_origins = ["${var.application_base_url}"]
  web_origins     = ["${var.application_base_url}"]
  grant_types     = ["implicit"]

  jwt_configuration = {
    # 60s * 60min *12h
    lifetime_in_seconds = "${var.jwt_lifetime}"
    secret_encoded      = true
    alg                 = "RS256"
  }

  #custom_login_page_on = true

  token_endpoint_auth_method = "none"
  client_metadata = {
    foo = "bar"
  }
}

causes crash

resource "auth0_client" "scheduling_app" {
  name            = "Scheduling App"
  description     = "An OIDC compliant authorization client for the scheduling backend .. Backend security (Managed by Terraform)"
  app_type        = "spa"
  is_first_party  = true
  oidc_conformant = true
  callbacks       = ["${var.application_base_url}${var.callback_endpoint}"]
  allowed_origins = ["${var.application_base_url}"]
  web_origins     = ["${var.application_base_url}"]
  grant_types     = ["implicit"]

  jwt_configuration = {
    # 60s * 60min *12h
    lifetime_in_seconds = "${var.jwt_lifetime}"
    secret_encoded      = true
    alg                 = "RS256"
  }

  #custom_login_page_on = true

  token_endpoint_auth_method = "none"
}

works as expected ....
the same definition worked fine in the past

Publish provider to the official Terraform registry

The provider doesn't cover all resources for Auth0, but it's usable in its current form (I can't say the same for official providers such as the Kubernetes provider).

I think you should publish it to the official registry. If this is not in your interest, feel free to close this issue.

Add version to end of provider name

Terraform uses the provider name to determine version information.

Thus, instead of

terraform-provider-auth0

the provider should be

terraform-provider-auth0_vX.Y.Z

Create terraform.io provider documentation

In order to participate in the provider developer program, each Terraform provider must have its own terraform.io website documentation that should reside under a website/ directory. There should be a page for each resource and data source as well as an index page for the provider. Along with with must be a ruby layout file to represent the side bar directory.

universal login settings are not supported

NB: we're more than happy to implement this and open a PR, but we thought we'd open a feature request first for any feedback or discussion.

Community Note

  • 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

In the Auth0 management UI, there's a Universal Login section:

https://manage.auth0.com/dashboard/us/$myTenantName/login_settings

You can do things like:

  • enable or disable Universal Login
  • decide whether to use the "classic" or "new" Universal Login Experience
  • set a Primary Color and Page Background Color

For our use case, these are the only settings we can't currently manage through the provider.

New or Affected Resource(s)

Either an addition to this resource:

auth0_tenant

Or a new resource named something like:

auth0_tenant_universal_login

Unfortunately, I can't actually find anything relevant in the Auth0 Management API documentation. If that's the reason it's not supported, then fair enough!

Potential Terraform Configuration

resource "auth0_tenant" "my-tenant" {
  // we've set the following params via the web UI
  //
  //flags = {
  //  universal_login = true,
  //  new_universal_login_experience_enabled = true
  //}
  //universal_login = {
  //  colors = {
  //    primary = "#00D8FF"
  //    page_background = "#001736"
  //  }
  //}
}

References

Missing dependency "git.apache.org/thrift.git"

Community Note

  • 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

Terraform Version

0.12.7

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

It should compile.

Actual Behavior

It can't download "apache thrift":

ยป make build
==> Checking that code complies with gofmt requirements...
go install
go: finding git.apache.org/thrift.git v0.0.0-20180902110319-2566ecd5d999
go: git.apache.org/[email protected]: git fetch -f https://git.apache.org/thrift.git refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /Users/jose/.gocode/pkg/mod/cache/vcs/83dba939f95a790e497d565fc4418400145a1a514f955fa052f662d56e920c3e: exit status 128:
	fatal: unable to access 'https://git.apache.org/thrift.git/': Failed to connect to git.apache.org port 443: Operation timed out
go: error loading module requirements
make: *** [build] Error 1

Steps to Reproduce

  1. clean your $GOPATH/pkg/mod/
  2. clone the repository
  3. run make build or go mod download

Important Factoids

I read in this issue that the project was moved to github. jenkins-x/jx#3320

I don't have much experience in GO and I can't determine what is the dependency using Apache Thrift.

References

Password Dictionary option broken on Connection resource

Community Note

  • 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

Terraform Version

Terraform v0.12.8

Affected Resource(s)

  • auth0_connection

Terraform Configuration Files

resource "auth0_connection" "database" {
  name                 = "database"
  strategy             = "auth0"
  is_domain_connection = false

  enabled_clients = [
    auth0_client.application.name
  ]

  options {
    brute_force_protection         = true
    disable_signup                 = false
    enabled_database_customization = false
    import_mode                    = false
    requires_username              = false
    password_policy                = "good"
    password_history {
      enable = true
      size   = 5
    }
    password_no_personal_info {
      enable = true
    }
    password_dictionary = {     # <--- This right here is broken
      enable = true
    }
  }
}

Expected Behavior

Auth0 Connection resource is successfully created with the Password Dictionary feature enabled.

Actual Behavior

Crash, password_dictionary.enable is sent to auth0 as a string instead of a bool:

...
          + password_dictionary            = {
              + "enable" = "true"          # <---- This is the downside of using map, the boolean is now a string
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions in workspace "dev"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

auth0_connection.database: Creating...

Error: 400 Bad Request: Payload validation error: 'Expected type boolean but found type string' on property options.password_dictionary.enable.

  on auth0.tf line 57, in resource "auth0_connection" "database":
  57: resource "auth0_connection" "database" {

Steps to Reproduce

  1. terraform apply

[BUG] Connection sends `strategy` and `name` on update

Looks related to #9.

When using a connection with strategy ad, and attempting to update (e.g to add clients), provider sends along the strategy and name, and we then get back: 400 Bad Request: Payload validation error: 'Additional properties not allowed: strategy,name'.

Not got much spare time at the moment to submit a PR, but might do in a few weeks if you don't manage to get around to it by then.

Signing secret in ResourceServer can't be updated

When a ResourceServer is created with signing_alg = "HS256" a signing_secret is created from Auth0. However this signing_secret is not stored in the state and when the terraform plan is called again the provider trues to set the signing_secret to empty string.

Terraform will perform the following actions:
  ~ module.module1.auth0_resource_server.api_resource_server
      signing_secret: "I9Fd1d832PZW82VsOXojlDFDIlkb3bwr" => ""

This results in an error from the Auth0 API:
400 Bad Request: Payload validation error: 'String is too short (0 chars), minimum 16' on property signing_secret (The secret used to sign tokens when using symmetric algorithms).

I would love to help fixing this issue if the authors could provide me a hint where to start!

auth0_role recreates roles if user got the role assigned

Community Note

  • 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

Terraform Version

0.12.16

Affected Resource(s)

  • auth0_role

Terraform Configuration Files

resource "auth0_role" "monitor_user_role" {
  name        = "${var.client_name}:user"
  description = "User of ${var.client_name}"

  permissions {
    resource_server_identifier = auth0_resource_server.app_api.identifier
    name                       = "read:units"
  }

  permissions {
    resource_server_identifier = auth0_resource_server.app_api.identifier
    name                       = "read:systems"
  }
}

Debug Output

Panic Output

Expected Behavior

After creating the roles they should stay even if they got assigned to users.

Actual Behavior

Roles are destroyed and created. All users lost their assigned roles.

Steps to Reproduce

  1. terraform apply
  2. Assign roles to users with auth0 web site.
  3. terraform apply

Important Factoids

References

Error Importing Non-blank Client

Terraform Crashes when importing a non-blank client. It worked fine when importing a blank client.

ยป terraform import module.foo_login.auth0_client.foo_login "ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n"
module.foo_login.auth0_client.foo_login: Importing from ID "ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n"...
module.foo_login.auth0_client.foo_login: Import complete!
  Imported auth0_client (ID: ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n)
module.foo_login.auth0_client.foo_login: Refreshing state... (ID: ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n)

Error: module.foo_login.auth0_client.foo_login (import id: ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n): 1 error(s) occurred:

* import module.foo_login.auth0_client.foo_login result: ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n: auth0_client.foo_login: unexpected EOF


panic: interface conversion: interface {} is map[string]interface {}, not *schema.Set
2018-08-20T06:03:03.312-0500 [DEBUG] plugin.terraform-provider-auth0:
2018-08-20T06:03:03.312-0500 [DEBUG] plugin.terraform-provider-auth0: goroutine 59 [running]:
2018-08-20T06:03:03.312-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).setSet(0xc42026e340, 0xc42022eac0, 0x1, 0x1, 0x18de5a0, 0xc4206f0000, 0xc4203d0780, 0x1, 0x6)
2018-08-20T06:03:03.312-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:343 +0xa63
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).set(0xc42026e340, 0xc42022eac0, 0x1, 0x1, 0x18de5a0, 0xc4206f0000, 0x1, 0x1)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:107 +0x2ac
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).WriteField(0xc42026e340, 0xc42022eac0, 0x1, 0x1, 0x18de5a0, 0xc4206f0000, 0x0, 0x0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:89 +0x46a
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*ResourceData).Set(0xc420396310, 0x1a01ade, 0x6, 0x18de5a0, 0xc4206f0000, 0x1af22e0, 0xc42022eab0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/resource_data.go:189 +0x12b
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/auth0.readClient(0xc420396310, 0x1982bc0, 0xc42044c000, 0xc420396310, 0x0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/auth0/resource_auth0_client.go:263 +0x8d0
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Refresh(0xc4203c28c0, 0xc4202661e0, 0x1982bc0, 0xc42044c000, 0xc4203c47d8, 0x10bd001, 0x185cb40)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:354 +0x167
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Refresh(0xc4203c3180, 0xc420266190, 0xc4202661e0, 0x18, 0x18, 0xc4202643a0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:308 +0x9a
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Refresh(0xc42000c600, 0xc4202780e0, 0xc420278290, 0x0, 0x0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/Users/mmaletich/go/src/github.com/yieldr/terraform-provider-auth0/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:549 +0x4e
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: reflect.Value.call(0xc420094a80, 0xc42000e440, 0x13, 0x1a0000b, 0x4, 0xc420065f18, 0x3, 0x3, 0xc4203b8ac0, 0x0, ...)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/usr/local/Cellar/go/1.10.3/libexec/src/reflect/value.go:447 +0x969
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: reflect.Value.Call(0xc420094a80, 0xc42000e440, 0x13, 0xc42037e718, 0x3, 0x3, 0x0, 0x0, 0x0)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/usr/local/Cellar/go/1.10.3/libexec/src/reflect/value.go:308 +0xa4
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: net/rpc.(*service).call(0xc420082900, 0xc42034a1e0, 0xc4200364d0, 0xc4200364e0, 0xc4203ba680, 0xc4203ec560, 0x185cb00, 0xc4202780e0, 0x16, 0x185cb40, ...)
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/usr/local/Cellar/go/1.10.3/libexec/src/net/rpc/server.go:384 +0x14e
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: created by net/rpc.(*Server).ServeCodec
2018-08-20T06:03:03.313-0500 [DEBUG] plugin.terraform-provider-auth0: 	/usr/local/Cellar/go/1.10.3/libexec/src/net/rpc/server.go:480 +0x43a
2018/08/20 06:03:03 [ERROR] root.foo_login: eval: *terraform.EvalRefresh, err: auth0_client.foo_login: unexpected EOF
2018/08/20 06:03:03 [ERROR] root.foo_login: eval: *terraform.EvalSequence, err: auth0_client.foo_login: unexpected EOF
2018/08/20 06:03:03 [TRACE] [walkImport] Exiting eval tree: import module.foo_login.auth0_client.foo_login result: ZmZ6Rao2EzsDXOY5ptwz6irH3lgq8G6n
2018/08/20 06:03:03 [TRACE] dag/walk: upstream errored, not walking "provider.auth0 (close)"
2018/08/20 06:03:03 [DEBUG] plugin: waiting for all plugin processes to complete...
2018-08-20T06:03:03.318-0500 [WARN ] plugin: error closing client during Kill: err="connection is shut down"
2018-08-20T06:03:03.318-0500 [DEBUG] plugin: plugin process exited: path=/Users/mmaletich/.terraform.d/plugins/terraform-provider-auth0



!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Terraform crashed! This is always indicative of a bug within Terraform.
A crash log has been placed at "crash.log" relative to your current
working directory. It would be immensely helpful if you could please
report the crash with Terraform[1] so that we can fix this.

When reporting bugs, please include your terraform version. That
information is available on the first line of crash.log. You can also
get it by running 'terraform --version' on the command line.

[1]: https://github.com/hashicorp/terraform/issues

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
------------------------------------------------------------

Terraform v0.11.7

Creating a client with is_first_party = false requires terraform applying twice

Noticing a strange behavior when trying to create third party clients (applications) via terraform (that is, when is_third_party = false) - the flag does not appear to take when the client is created, but does on subsequent updates.

resource "auth0_client" "mds_provider" {
  name = "foobar"
  is_first_party = false
}

When running TF_LOG=DEBUG AUTH0_DEBUG=1 terraform apply, see the following relevant outputs (full output can be viewed here)

Terraform will perform the following actions:

  + module.mds-api-auth.auth0_client.mds_provider
      id:                                  <computed>
      client_id:                           <computed>
      client_secret:                       <computed>
      custom_login_page_on:                <computed>
      grant_types.#:                       <computed>
      is_first_party:                      "false"
      is_token_endpoint_ip_header_trusted: <computed>
      name:                                "foobar"
      token_endpoint_auth_method:          <computed>


Plan: 1 to add, 0 to change, 0 to destroy.

module.mds-api-auth.auth0_client.mds_provider: Creating...
  client_id:                           "" => "<computed>"
  client_secret:                       "<sensitive>" => "<sensitive>"
  custom_login_page_on:                "" => "<computed>"
  grant_types.#:                       "" => "<computed>"
  is_first_party:                      "" => "false"
  is_token_endpoint_ip_header_trusted: "" => "<computed>"
  name:                                "" => "foobar"
  token_endpoint_auth_method:          "" => "<computed>"
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: 2019/03/22 16:11:59 POST /api/v2/clients HTTP/1.1
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Host: REDACTED 
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Content-Type: application/json
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0:
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0:
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: HTTP/2.0 201 Created
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Content-Type: application/json; charset=utf-8
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Date: Fri, 22 Mar 2019 23:11:59 GMT
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Strict-Transport-Security: max-age=15724800
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: Vary: origin,accept-encoding  
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: X-Ratelimit-Limit: 10
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: X-Ratelimit-Remaining: 9
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: X-Ratelimit-Reset: 1553296321 
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0:
2019-03-22T16:11:59.878-0700 [DEBUG] plugin.terraform-provider-auth0: {"tenant":"REDACTED","global":false,"is_token_endpoint_ip_header_trusted":false,"name":"foobar","is_first_party":true,"sso_disabled":false,"cross_origin_auth":false,"oidc_conformant":false,"encrypted":true,"signing_keys":[REDACTED],"client_id":"hIJWkYMhFhHJUE7kdmw7NconvmfiTV0p","callback_url_template":false,"client_secret":"REDACTED","jwt_configuration":{"lifetime_in_seconds":36000,"secret_encoded":false},"grant_types":["authorization_code","implicit","refresh_token","client_credentials"],"custom_login_page_on":true}

Note, even in the response to the creation POST, Auth0 responds with "is_first_party":true.

Subsequently applying yields this plan:

Terraform will perform the following actions:

  ~ module.mds-api-auth.auth0_client.mds_provider
      is_first_party: "true" => "false"

and the modification succeeds.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.