superseded by #320

Description

Connection resources with windowslive strategy do not send options parameters to the Auth0 management API. It seems this may be intentionally unsupported https://github.com/alexkappa/terraform-provider-auth0/blob/v0.17.2/auth0/structure_auth0_connection.go#L271

Terraform Version

Terraform 0.13.6
+ provider.auth0 0.17.2

Affected Resource(s)

• auth0_connection

Terraform Configuration Files

resource "auth0_connection" "windowslive" {
  name                = "windowslive"
  strategy            = "windowslive"
  options {
    client_id         = var.microsoft.client_id
    client_secret     = var.microsoft.client_secret
    strategy_version  = 2
    scopes            = ["https://graph.microsoft.com/User.Read"]
  }	 
}

Expected Behavior

A POST body should be sent to the management API with a JSON body containing ... "options": {"client_id":"<client ID>" ...

Actual Behavior

A connection resource is created in Auth0 with no options configured.

Steps to Reproduce

1. terraform apply

Debug Output

We consistently produce this warning:

2021-01-15T19:52:12.333-0500 [DEBUG] plugin.terraform-provider-auth0_v0.17.2: 2021/01/15 19:52:12 [WARN]: Unsupported connection strategy windowslive

from the default branch here.

<!--- Please keep this note for the community --->

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

<!--- Thank you for keeping this note for the community --->

<!--- IMPORTANT: Please submit issues or pull requests to alexkappa/terraform-provider-auth0. This helps maintainers organize work more efficiently.

Use the link below if you are not certain: https://github.com/alexkappa/terraform-provider-auth0/issues/new --->

Description

<!--- Please give a helpful description of the issue here. --->

<!--- Please note the following potential times when an issue might be in Terraform core:

• Configuration Language or resource ordering issues
• State and State Backend issues
• Provisioner issues
• Registry issues
• Spans resources across multiple providers

If you are running into one of these scenarios, we recommend opening an issue in the Terraform core repository instead. --->

Terraform Version

<!--- Please run terraform -v to show the Auth0 provider version as well as the Terraform core version.

If you are not running the latest version of Terraform or the provider, please upgrade because your issue may have already been fixed. Terraform documentation on provider versioning. --->

Terraform <TERRAFORM_VERSION>
+ provider.auth0 <TERRAFORM_PROVIDER_VERSION>

Affected Resource(s)

<!--- Please list the affected resources and data sources. --->

• auth0_XXXXX

Terraform Configuration Files

<!--- Information about code formatting: https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code --->

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a [Github Gist](https://gist.github.com/) instead.

Expected Behavior

<!--- What should have happened? --->

Actual Behavior

<!--- What actually happened? --->

Steps to Reproduce

<!--- Please list the steps required to reproduce the issue. --->

1. terraform apply

Debug Output

<!--- Please provide a link to a GitHub Gist containing the complete debug output. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

To obtain the debug output, define the TF_LOG=debug and AUTH0_DEBUG=true environment variables before running terraform apply.

For more info see the Terraform documentation on debugging. --->

Panic Output

<!--- If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log. --->

Important Factoids

<!--- Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? --->

References

<!--- Information about referencing Github Issues: https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests

Are there any other GitHub issues (open or closed) or pull requests that should be linked here? Vendor documentation? For example: --->

• #0000

<!--- Please keep this note for the community --->

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

<!--- Thank you for keeping this note for the community --->

Closing and re-opening--I seem to have lost the issue content.

<!--- IMPORTANT: Please submit issues or pull requests to alexkappa/terraform-provider-auth0. This helps maintainers organize work more efficiently.

Use the link below if you are not certain: https://github.com/alexkappa/terraform-provider-auth0/issues/new --->

Description

<!--- Please give a helpful description of the issue here. --->

<!--- Please note the following potential times when an issue might be in Terraform core:

• Configuration Language or resource ordering issues
• State and State Backend issues
• Provisioner issues
• Registry issues
• Spans resources across multiple providers

If you are running into one of these scenarios, we recommend opening an issue in the Terraform core repository instead. --->

Terraform Version

<!--- Please run terraform -v to show the Auth0 provider version as well as the Terraform core version.

If you are not running the latest version of Terraform or the provider, please upgrade because your issue may have already been fixed. Terraform documentation on provider versioning. --->

Terraform <TERRAFORM_VERSION>
+ provider.auth0 <TERRAFORM_PROVIDER_VERSION>

Affected Resource(s)

<!--- Please list the affected resources and data sources. --->

• auth0_XXXXX

Terraform Configuration Files

<!--- Information about code formatting: https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code --->

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a [Github Gist](https://gist.github.com/) instead.

Expected Behavior

<!--- What should have happened? --->

Actual Behavior

<!--- What actually happened? --->

Steps to Reproduce

<!--- Please list the steps required to reproduce the issue. --->

1. terraform apply

Debug Output

<!--- Please provide a link to a GitHub Gist containing the complete debug output. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

To obtain the debug output, define the TF_LOG=debug and AUTH0_DEBUG=true environment variables before running terraform apply.

For more info see the Terraform documentation on debugging. --->

Panic Output

<!--- If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log. --->

Important Factoids

<!--- Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? --->

References

<!--- Information about referencing Github Issues: https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests

Are there any other GitHub issues (open or closed) or pull requests that should be linked here? Vendor documentation? For example: --->

• #0000

<!--- Please keep this note for the community --->

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

<!--- Thank you for keeping this note for the community --->

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

This PR has become stale as it has been open 30 days with no activity. Stale PRs will be closed after 5 days if no action is taken. If you think this PR should not be closed, remove the stale label.

This PR has become stale as it has been open 30 days with no activity. Stale PRs will be closed after 5 days if no action is taken. If you think this PR should not be closed, remove the stale label.

This PR has become stale as it has been open 30 days with no activity. Stale PRs will be closed after 5 days if no action is taken. If you think this PR should not be closed, remove the stale label.

<!--

IMPORTANT: Please submit issues or pull requests to alexkappa/terraform-provider-auth0. This helps maintainers organize work more efficiently.

Use the link below if you are not certain: https://github.com/alexkappa/terraform-provider-auth0/issues/new

-->

Description

<!--- Please leave a helpful description of the feature request here. --->

Add support for the MFA configuration supported by the API https://auth0.com/docs/api/management/v2#!/Guardian.

New or Affected Resource(s)

<!--- Please list the new or affected resources and data sources. --->

• auth0_guardian

Potential Terraform Configuration

<!--- Information about code formatting: https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code --->

resource "auth0_guardian" {
  require_mfa = "always" // or "never"
  factors {
    otp {
      enabled = true
    }
    // phone, guardian, email, duo
    // default enabled = false
  }
}

References

<!--- Information about referencing Github Issues: https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests

Are there any other GitHub issues (open or closed) or pull requests that should be linked here? Vendor blog posts or documentation? For example:

• https://auth0.com/docs/api/management/v2 --->

• https://auth0.com/docs/api/management/v2#!/Guardian

<!--- Please keep this note for the community --->

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

<!--- Thank you for keeping this note for the community --->

Rollbacked the `authorizationUrl" redirect feature removed by https://github.com/cloudendpoints/esp/pull/824

Add a new flag --redirect_authorization_url to guard this feature. This feature is only enabled when this flag is specified.

PTAL

Done

Done

SG

how about --enable_jwt_authorization_url_redirect

How about jwt_redirect_authorization_url?

The current name just reminds me of service control check authz.

How about If set to true, authentication failed requests will be redirected to the URL specified by theauthorizationUrlfield in OpenAPI spec. The default is false.?

Nit: enable_redirect_to_authorization_url

Current name makes it sound like the flag accepts a URL string as a param.

Rollbacked the `authorizationUrl" redirect feature removed by https://github.com/cloudendpoints/esp/pull/824

Add a new flag --redirect_authorization_url to guard this feature. This feature is only enabled when this flag is specified.

OK, let us add his feature back under a flag. My judgement is: most people don't use it, but they get confused when we redirect to that URL silently. For the new users that want the redirect feature, they can enable it explicitly.

BTW, ESPv2 doesn't have this feature, we need to add it to ESPv2 too.

What do you think @qiwzhang? Worst case we can revert this PR and place this behavior around a feature flag (disabled by default, @pulidon can enable it).

@qiwzhang @nareddyt @TAOXUY, this fueature shoudn't have been removed, as 'authorizationUrl' is a required parameter by the OpenAPI Specification https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityDefinitionsObject, furthemore if I'm using other authentication systems like (Auth0, Firebase) I should have the functionality to send not authenticated users to the authentication portal. please let me know if I should create a Issue or reopen the previous one.

closes #317

Added the line channel_id and channel_secret options for the line connection strategy.

Description

I am using your awesome provider via pulumi https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/auth0/#Provider

It seems like the Line connection strategy is missing some options, namely the channel_id and channel_secret.

https://github.com/alexkappa/terraform-provider-auth0/blob/master/auth0/resource_auth0_connection.go#L235

I cannot verify if the auth0 management api supports these options, as I cannot find connection options for each strategy in the management api docs. If you know a better place to find supported strategy options than https://auth0.com/docs/api/management/v2#!/Connections/post_connections I am all ears.

As it stands I need to manually set the channel id and channel secrets for line connections via the auth0 ui.

New or Affected Resource(s)

auth0_connection https://github.com/alexkappa/terraform-provider-auth0/blob/master/auth0/resource_auth0_connection.go#L235

Thanks in advance for any help / insight into the issue.

Hi,

Any ideas what could be causing this error mid import?

dacite.exceptions.WrongTypeError: wrong value type for field "revenue_accounts" - should be "typing.Dict[str, dict]" instead of value "{Redacted list of YNAB payees} of type "dict"

I'm running ESP in GKE, following https://cloud.google.com/endpoints/docs/openapi/get-started-kubernetes-engine

I have a microservices architecture, with multiple services running in different containers in the cluster.

• When I deploy ESP with --backend my-service-name:80, endpoints are correctly routed to the service my-service-name.
• When I deploy ESP with --enable_backend_routing and include x-google-backend on a per-operation basis in my openapi.yml, so that I can route different operations to different backends, I can't seem to route properly with the service name. The IP address of the service works, but that's not a stable solution.

paths:
  "/v1/some-path":
    post:
      x-google-backend:
        address: "http://my-service-name:80"
        path_translation: APPEND_PATH_TO_ADDRESS

gives me 503 Bad Gateway in my requests, and my-service-name could not be resolved (3: Host not found) in my logs. The same setup with the IP address works, but as noted above it's not a solution.

Is there a way to route to the service by name on a per-operation basis?

Cool. I am glad to hear that.

Upgraded to ESPv2, that seems to fix it! Now working with address: "http://my-service-name:80"