-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws_cognito_user_pool support temporary password validity days in password policy #8827
Comments
I got redirected here from #21561 but getting this error: Error: Unsupported argument on main.tf line 38, in resource "aws_cognito_user_pool" "users": An argument named "temporary_password_validity_days" is not expected here. My config looks like this: password_policy { Terraform version 0.12, aws.provider version 2.13 Any ideas? |
@omarelsaid The |
I can confirm that @kradical workaround works. We executed the following AWS CLI command and after that we were able to apply our terraform scripts again: |
Glad it worked for you! I randomly stumbled across it while desperately trying to get our builds going again 😂 . Full comment they are referring to: #8845 (comment) |
Any updates on this one? I am getting aws_cognito_user_pool.pool: Error updating Cognito User pool: InvalidParameterException: Please use TemporaryPasswordValidityDays instead of UnusedAccountValidityDays not using unused_account_validity_days or temporary_password_validity_days in the config |
Not using either? Ooh that's not good. You can try the CLI workaround in the PR to "reset" the cognito user pool to using the old parameter. Although I wouldn't recommend using it on anything production, only development things. Trying to add the new field in a backwards compatible way is proving difficult. We might have to just add it and default to the new field. I am waiting to hear back from maintainers. |
Yeah. Recreating the whole environment (avoiding both fields) fixed it until today. Nobody touched them on purpose (knowing it will be bad) but they returned anyway. |
Found a way to fix my problem without recreating anything. I just had to run
before doing a normal |
Be aware that any property of the cognito pool which is not default will be overwritten with this AWS CLI command eg. MFA on -> MFA off |
Be aware that any property of the cognito pool which is not default will be overwritten with this AWS CLI command eg. MFA on -> MFA off |
It worked for me with '{"AllowAdminCreateUserOnly": true}' instead of '{"AllowAdminCreateUserOnly": false}' (because it was already false) |
We built a preview of this fix, it worked for us. |
When this will be released? |
Any updates? |
@nikitacr7 Update: I closed the original PR because it looks like AWS has started removing the old parameter in some regions. So instead of trying to accommodate the old parameter IMO there should be a new PR to just do the swap. I have too much on my plate to do it, but it should hopefully be relatively straightforward. |
@kradical It'd be very helpful if you will find some time to do it, because all my terraform stuff around cognito is blocked right now. Thanks!!! |
TBH I don't even use this library anymore so I'm not going to do it. Maybe someone who's livelyhood depends on this bugfix should fix it 😂 |
Hello when will you fix this issue? It is very annoying. We are stuck at this moment and we could not go in production with that. |
This is a blocker for us as well. I'm very surprised such a critical issues has not been resolved in close to 6 months now. |
work around for the unused_account_validity_days do not work anymore.. seems like eu-west-1 region does not allow this any longer. cant seem to find a way out of this issue :-( |
Still an issue. Right now I have to manually update anything that falls under This started happening after someone manually save some changes manually to our Email template through the Console. |
Still an issue. |
Blocker for me too. Cognito support in eu-central-1 is fairly useless until this is fixed :( I notice the issue has just an "enhancement" label - perhaps someone can add a more appropriate label? I presume breaking-change? |
We have the same issue. It seems like AWS has deprecated some configuration in eu-west-1 |
This has become an issue in us-west-2 as well. |
Same issue in ap-northeast-1, is this going to be fixed ? |
eu-west-2 started to be affected too. |
Looks like adding missing field fixes the issue - #10890 |
We found out that this might not be regional change, actually if you try to update certain configuration for your userpool using AWS Console the object is being "converted" newer version under the hood. |
Affected by the same issues. Only way to work around this, when possible, is to just to update via console any changes and then make sure terraform is up to parity with console changes. |
I solved this by setting the |
@mpxr thanks I'm certain you just saved me at least an hour of messing about. |
This is still an issue, best way I found to avoid the problem is to simply tell Terraform to ignore any changes:
And do every change manually on the console. Not ideal but it works for the time bein |
If anyones interested in trying to make #10890 backwards compatible, feel free to. Doubt I'll have any more time for this. |
This has been released in version 2.47.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks! |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Community Note
Description
Amazon has changed the way temporary password expiry is specified. See references.
Specifically
UnusedAccountValidityDays
inAdminCreateUserConfigType
is being moved to
TemporaryPasswordValidityDays
inPasswordPolicyType
The way it works is that you can continue to use the first option but as soon as you specify the second option for a user pool the first option is deprecated and unusable for that user pool.
I think we can either make a clean break and move to the second option or we have to make both fields optional with no default provided to support both use cases. I definitely prefer the first option but it definitely breaks terraform API BC and could have implications by "implicitly" deprecating the first option in anybody's user pool that runs terraform.
I am going to take a crack at implementing this myself, probably the optional way because that will make the most people happy. And then once the deprecated field is removed we can remove it from here too 🤷♂ .
New or Affected Resource(s)
Potential Terraform Configuration
References
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUserConfigType.html
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_PasswordPolicyType.html
The text was updated successfully, but these errors were encountered: