I managed to corrupt the Connection entity and break Auth0

[spenceclark]

Description

Not sure if this is something I did wrong, or if it is a bug in this provider, or a bug in the Auth0 API...

I was using the auth0_connection resource. I had used terraform import to map my existing "Username-Password-Authentication" connection to the one below.

After applying the below resource, suddenly all Auth0 calls that touched that connection (e.g. token endpoint) were hanging and eventually returning a 504 error for Auth0

Reapplying in terraform didn't fix it.

After some digging, I noticed that if I called the Auth0 "Get Connection API" directly, it returned a value of NULL for the non_persistent_attrs property, which wasn't a field I was specifiying. I copied the JSON back into a PATCH request to the API, removing the non_persistent_attrs field from the request. This resolved the problem and the Auth0 endpoints started working again.

When I reapplied via Terraform it broke again as it had set non_persistent_attrs back to NULL.

In the end I updated my terraform to set non_persistent_attrs to a value, and that now allows me to apply changes via terraform without breaking anything.

Terraform Version

Terraform v0.15.1
+ provider registry.terraform.io/alexkappa/auth0 v0.21.0

Affected Resource(s)

auth0_connection

Terraform Configuration Files

resource "auth0_connection" "db" {
  name = "Username-Password-Authentication"
  strategy = "auth0"
  is_domain_connection = false
  options {
    requires_username = false
    disable_signup = true
    password_policy = "good"
    password_history {
      enable = false
      size = 5
    }
    password_dictionary {
      enable = true
    }
    password_no_personal_info {
      enable = true
    }
    brute_force_protection = true
    mfa {
      active = true
      return_enroll_settings = true
    }
    import_mode = false
    strategy_version = 2
    password_complexity_options {
      min_length = 8
    }
    enabled_database_customization = false
  }
}

Expected Behavior

The Connection should have updated and been in a useable state

Actual Behavior

The connection was updated, but Auth0 broke and gave a 504 error when connection was used.

Steps to Reproduce

1. Create the resource file above
2. Use terraform import to map this to the default connection records in an Auth0 tenant
3. Run terraform apply
4. Attempt to call the /oauth/token endpoint in Auth0. This is the call that hung and eventually died witha 504 error.

Debug Output

I didn't capture any sorry

Panic Output

None

Important Factoids

I am using the terraform cloud platform to hold state and run the apply commands.

I fixed the problem by adding non_persistent_attrs = [ "shoe_size" ] to my terraform resource

References

None

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

[yvovandoorn]

@spenceclark thanks for the report. So 0.21.1 includes #376, which included functionality around this.

Let me do some testing on my end to see if I can repro it.

[spenceclark]

We also raised a ticket with Auth0 in case it was something on their side. They just came back with this:

Good catch. Indeed, what you mentioned is what was causing the issue.
Our Engineering team was also able to reproduce. We are working on fixing that, as it should not happen.
We will let you know when we have news regarding this.

[chrishurlburt]

I also encountered this issue when provisioning an auth0 DB connection via TF. After many hours spent debugging, i was able to narrow it down to the connection. Seeing the same non_persistent_attrs coming back as null.

Are we thinking this is an issue with the TF provider or an issue with the auth0 management API?

[franklouwers]

We have the same issue. Auth0 fully blames this on "your use of a not officially supported terraform module". They do provide a workaround which is to set the non_persistent_attrs array to something non-empty.

[erdengel-noah]

We received a better and working workaround. Empty string has been set and processed correctly:
We are currently testing if the provider is setting it correctly. According to plan & execution, it had been set to [], however ended up as null in the auth0 teanant. The workaround works however, so it means that the ManangmentApi processes an empty array correctly.

---

Workaround:

Get a token for the management API:

https://auth0.com/docs/tokens/management-api-access-tokens#get-management-api-tokens

Use the Management API and perform a GET to retrieve the connection (the DB connection):

https://auth0.com/docs/api/management/v2#!/Connections/get_connections_by_id

WARNING: You MUST copy your existing options before patching, failure to do so may result in database options being lost or reset to unintended values.

Copy the existing Options and then Patch the connection with "non_persistent_attrs":[]

https://auth0.com/docs/api/management/v2#!/Connections/patch_connections_by_id

Example Patch payload:

{
"options": {
...[YOUR EXISTING OPTIONS]...,
"non_persistent_attrs":[]
}
}

[alexkappa]

Hey, @spenceclark thanks for reporting, and apologies for the inconvenience.

I believe that the root of the problem originates from the fact that non_persistent_attrs is specified as a *[]string which breaks conventions in the SDK.

This created a need in the provider for the castToListOfStrings method which is also likely to be adding to the problem.

The omitempty on NonPersistentAttrs will instruct encoding/json to not marshal the field if it's not nil/empty. Since the return value of castToListOfStrings is never empty, it will be always written. In the case of *[]string a pointer to an empty array is not considered empty, because the pointer is not nil.

We probably need to revert *[]string back to []interface{} and here, let Set(d, "non_persistent_attrs").List() to do the right thing.

[brandonbyskov]

I also encountered this issue when upgrading from version 0.20.0 to 0.21.0. All connections broke and users couldn't log in through the connections until I applied the workaround discussed here.

This seems like a serious issue that will likely affect all consumers of this terraform provider when they try to upgrade. This should be posted as a known issue in the Changelog or Readme. The workaround should be posted for others if this isn't fixed. I wouldn't want anyone else to go through the inconvenience all of us had to.

I followed workarounds discussed here. The one posted by @franklouwers seems to be the cleanest that worked for me. I had to add the following to every connection:

resource "auth0_connection" "example-connection" {
  ...
  options {
    ...
    non_persistent_attrs = [""] # workaround for bug: https://github.com/alexkappa/terraform-provider-auth0/issues/382
  }
}

[sergiught]

This relates to several other issues that are present within the provider and I have captured this along with the others within auth0/terraform-provider-auth0#14.

As this repo has moved over at https://github.com/auth0/terraform-provider-auth0 please open new issues over there from now on.