-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Cyrillic email domain in Cognito UserPool does not work #8473
Comments
After all I've found that Cyrillic domain name can be specified in Punycode. But it still would be nice to get an error on a non-ASCII character instead of producing an invalid CloudFormation template. |
Can you paste the section with |
Sorry, @nija-at but I don't have it anymore. But that domain parameter was simply |
This worked just fine for me. Here's the generated CloudFormation template -
You'll need to check the encoding settings in your environment or provide more details. |
Is this what you see locally or in cloud formation console? The question marks I’ve seen are on CF console stack’s template tab |
This is what is shown locally on CF template. It's possible that the the console web UI mangles the characters but is actually correctly set up. Can you check whether an email sent via this user pool is actually correctly set up? |
No it was not. As you can see in original post, there was |
I'm going to gander a guess and say this is where the confusion happened:
I'm guessing that Niranjan saw that remark, missed the error message, and thought the template had deployed successfully. @nija-at as a reminder of one of those niggling CloudFormation gotchas, if a stack fails to create (so not fails to update, but fails to create, on the first attempt) then it will still show the template you were trying to deploy. So it is possible for a stack to NOT be successfully created an still have template for you to look at in the console. At the same time, I wouldn't be suprised the CloudFormation console doesn't handle unicode characters properly and shows |
I mean, automatically encoding unicode -> punycode for domain names would totally be in the "do the right thing" charter for CDK to do. I'm just a little worried about the dependencies required to do it. Let me have a look-see. |
Correct. The deployment indeed fails. |
Okay punycode package has 0 dependencies. That's not too shabby... |
A validation in the CDK here would be a fine first step. Open for anyone who wants to submit a PR. |
If an email address for cognito email settings contains a non-ascii character, the cognito cdk package applies punycode encoding, which cloudformation will pick up properly. This pull request adds the [`punycode`](https://github.com/bestiejs/punycode.js) package to the dependencies, as previously discussed in #8473. The package occupies 42KB in `node_modules` after installation. I am not sure if I configured the package correctly to be included in the cdk build. The project itself added `punycode` to `aws-cdk-lib` and `monocdk`, I had to re-run `yarn install` in these packages. Unit- and integration tests are added, but notice that I could not manage a manual e2e test, I think I need to own a domain with non-ascii letters to do so, which I currently do not. A similar approach as in this PR will also be interesting for other cdk packages which deal with email addresses and domains, like hosted zones. According to the [Cfn Domain Name Format Docs](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DomainNameFormat.html), characters with code point below 33, or in `[127, 255]` should be escaped with an octal code, which is not applied in this pull request. Fixes #8473 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
It's not possible to use Cyrillic domain name like
домен.рф
in Cognito UserPool email settings.Reproduction Steps
Error Log
The generated CloudFormation template (as seen in AWS Console) has question marks instead of Cyrillic characters.
Environment
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: