Add support for OAuth scope handling #282
Conversation
* scope_handling_policy * unknown_scope_policy * relationship * consent_mode Add userinfo_populate_lambda_id
| "scope_handling_policy": { | ||
| Type: schema.TypeString, | ||
| Optional: true, | ||
| Default: fusionauth.OAuthScopeHandlingPolicy_Strict.String(), |
There was a problem hiding this comment.
While this matches the API defaults, should we make it default to Compatibility to prevent breaking existing TF configs?
It may be possible to add some special handling so that it only sets it to Strict on create, and not overwrite existing applications.
There was a problem hiding this comment.
I think that it's good to keep the same default between the API and TF. It wasn't immediately obvious how to customize the default, but I would assume it's possible. It sounds like the Default here is static and cannot be customized.
CustomizeDiff could be useful, but that may only be used to decide whether changes need to be applied.
The issue is still present in older versions of the provider. I believe that's because the provider uses PUT instead of PATCH methods on the client calls. With no value provided, it will use the default of Strict in the API.
The data migration for 1.50.0 includes setting existing applications to Compatibility mode. Would it be unreasonable to expect provider users to update their TF state after an upgrade? If the new fields are available on the provider resource, I would expect that updating the state would pull in the migrated values from the application and then continue setting them when the configuration is applied in the future.
| "scope_handling_policy": { | ||
| Type: schema.TypeString, | ||
| Optional: true, | ||
| Default: fusionauth.OAuthScopeHandlingPolicy_Strict.String(), |
There was a problem hiding this comment.
I think that it's good to keep the same default between the API and TF. It wasn't immediately obvious how to customize the default, but I would assume it's possible. It sounds like the Default here is static and cannot be customized.
CustomizeDiff could be useful, but that may only be used to decide whether changes need to be applied.
The issue is still present in older versions of the provider. I believe that's because the provider uses PUT instead of PATCH methods on the client calls. With no value provided, it will use the default of Strict in the API.
The data migration for 1.50.0 includes setting existing applications to Compatibility mode. Would it be unreasonable to expect provider users to update their TF state after an upgrade? If the new fields are available on the provider resource, I would expect that updating the state would pull in the migrated values from the application and then continue setting them when the configuration is applied in the future.
Co-authored-by: Spencer Witt <spencer.witt@gmail.com>
| Elem: newOAuthConfigurationScopePolicy(), | ||
| "scope_handling_policy": { | ||
| Type: schema.TypeString, | ||
| Optional: true, |
There was a problem hiding this comment.
Let's make this field required as discussed. The data migration set this to Compatibility to maintain backwards compatibility, but new applications set it to Strict.
| }, | ||
| "unknown_scope_policy": { | ||
| Type: schema.TypeString, | ||
| Optional: true, |
There was a problem hiding this comment.
Let's make this one required as well. The migration set this to Allow in case existing applications were relying on unknown scopes being passed through. New applications set this to Reject by default.
Add OAuth configuration support for:
Add userinfo_populate_lambda_id.
Update provided_scope_policy to not want to re-apply on every run.
Fixes #283