Questions tagged with Amazon Cognito User Pools

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Cognito Allow all 3 Aliases (Email, Phone, and Username)

I have a ReactJS app and am creating a user portal for that website, with user accounts managed by Cognito. I am using [amazon-cognito-identity-js](https://www.npmjs.com/package/amazon-cognito-identity-js) in my ReactJS layer to register users with a User Pool. **Specifically, I want to allow users the flexibility to log into their user accounts with phone number, email address, and preferred username as aliases.** In order to use email address and phone number as aliases, both must be verified using OTPs. In order to use the signUp API in **amazon-cognito-identity-js**, a username must be provided. In this case, this username cannot be the email address or the phone number, since both are to be used as aliases. This is per [User Pool Attributes - Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases), which states: > If you select email address as an alias, Amazon Cognito doesn't accept a user name that matches a valid email address format. Similarly, if you select phone number as an alias, Amazon Cognito doesn't accept a user name for that user pool that matches a valid phone number format. Further, once the user's account is confirmed by verifying their phone number or email address, you can allow the user to set a preferred username. You cannot establish their preferred username as a username when registering: > Activate the preferred_username attribute so that your user can change the user name that they use to sign in while their username attribute value doesn't change. If you want to set up this user experience, submit the new username value as a preferred_username and choose preferred_username as an alias. Then users can sign in with the new value that they entered. If you select preferred_username as an alias, your user can provide the value only when they confirm an account. They can't provide the value during registration. So, what I'd like to get some assurance on is **what to provide Cognito for the username when calling the signUp API**. When creating users using only their email addresses as a username, you provide the email address for the username parameter when calling the signUp API. The username is then set to the supplied email address. Something must be provided for the username parameter to Cognito's signUp API, and in this case it cannot be an email address or phone number. I've tested this and whatever I provide for the username parameter can be used for logging into the user account, even after setting the preferred_username. In essence, the account can then be accessed by TWO different usernames, plus the phone and email aliases. **Is having this "original username" in addition to the other three username values considered legit and safe? Should I generate a UUID myself in the javascript code for the username parameter, using a library such as [UUID - npm](https://www.npmjs.com/package/uuid)? Or is there a different way so that the only three user IDs are limited to the phone number, email address, and preferred_username?**
1
answers
0
votes
26
views
asked 10 days ago

Still getting Intermittent ConnectTimeoutError when accessing SSM in Docker

A few months ago, I posted about a timeout error I'm getting from the SSM service. I'm still seeing the problem. Here's [the original thread](https://repost.aws/questions/QUpGBax4uuR82ubxwKjIZz8g/intermittent-connect-timeout-error-accessing-ssm). It's intermittent, but frustratingly common (often every 30–120 min) during development when my Flask server is restarting all the time and thus hitting the SSM endpoint as often as I press Save (so maybe bursts of 5–20 hits a minute). But this is FAR below the endpoint's limit, and I'm getting a timeout error and not a throttling error. To my knowledge, I haven't seen the error when the container is running on ECS, it's only an issue in local development. But ~5 people on my team are seeing the same behvaior when using **different ISPs in multiple countries.** The SSM host is reachable from outside the container, but once the issue appears, the container will be unable to access this host (and JUST this host) for 5–10 minutes. Connections to other URLs work fine. Restarting the container doesn't help. Using VPN to change my IP doesn't help. I'm at my wit's end, and it's really impeding local development at this point. I'm at a loss for how the problem is *only* affecting SSM, it really seems like it must be something to do with either Docker or AWS. I've looked, and I see the `GetParametersByPath` events in CloudTrail when things are working normally, but nothing when the connection is failing. I really need a solution to this. Can anyone suggest other things to try? **UPDATE 2022-11-04:** I have noticed a similar issue with Cognito. One of the first things my app does upon launching and receiving a new request is to try to connect to Cognito to fetch the JWKS in order to verify the JWT. From outside the container, this succeeds in about a second: ``` $ curl https://cognito-idp.us-east-2.amazonaws.com/us-east-2_xxxxxxxx/.well-known/jwks.json {"keys":[{"alg":"RS256","e":"AQAB","kid":" […] ``` But when I open a shell into the container that's stuck waiting for Cognito, Python can't reach the host: ``` >>> import requests >>> requests.get("https://apple.com") # Returns instantly <Response [200]> >>> requests.get("https://cognito-idp.ap-southeast-1.amazonaws.com/ap-southeast-1_ie577myCv/.well-known/jwks.json") # Returns relatively quickly <Response [404]> >>> requests.get("https://cognito-idp.us-east-2.amazonaws.com/us-east-2_xxxxxxxx/.well-known/jwks.json") # Hangs for a long time ``` Eventually, the host comes back. But WHY is it reachable with no problems from outside the container?? I'm caching the JWKS, so I only need to send the request once at the time of first request. But that's enough to bring my app to a standstill…
1
answers
0
votes
14
views
nk9
asked 25 days ago

Problems selecting cognito user pool in appsync

I have user pools in different regions. I can select the user pools from N. Virginia fine. But when selecting Stockholm it says there are no user pools in this region even though I have 2 created with the same settings as the one in N. Virginia. In the console I get this error: ``` main.js:263 Refused to connect to 'https://cognito-idp.eu-north-1.amazonaws.com/' because it violates the following Content Security Policy directive: "connect-src https://eu-north-1.console.aws.amazon.com/appsync/tb/creds https://eu-north-1.console.aws.amazon.com/p/ https://eu-north-1.console.aws.amazon.com/phd/ https://*.ccs.amazonaws.com https://eu-north-1.console.aws.amazon.com/api/ https://us-east-1.console.aws.amazon.com/feedback/custsat/ https://*.analytics.console.aws.a2z.com https://console.aws.amazon.com/aperture/ https://console.aws.amazon.com/panoramaroute https://console.aws.amazon.com/panoramaroute/allowlist https://phd.aws.amazon.com https://unifiedsearch.amazonaws.com/search https://eu-north-1.console.aws.amazon.com/panoramaroute https://eu-north-1.console.aws.amazon.com/panoramaroute/allowlist https://ccs.amazonaws.com https://global.console.aws.amazon.com/lotus/metadata https://eu-north-1.console.aws.amazon.com/lotus/metadata https://eu-north-1.prod.signer.console-api.aws.amazon.com https://health.aws.amazon.com https://us-east-1.ctrl.prod.os.notifications.aws.dev https://eu-north-1.console.aws.amazon.com/features-proxy/ https://telemetry.cell-0.eu-north-1.prod.tangerinebox.console.aws.a2z.com/telemetry https://cognito-idp.us-west-2.amazonaws.com https://cognito-idp.us-east-1.amazonaws.com https://cognito-idp.us-east-2.amazonaws.com https://cognito-idp.eu-west-1.amazonaws.com https://cognito-idp.eu-west-2.amazonaws.com https://cognito-idp.ap-southeast-2.amazonaws.com https://cognito-idp.ap-northeast-1.amazonaws.com https://cognito-idp.eu-central-1.amazonaws.com https://cognito-idp.ap-southeast-1.amazonaws.com https://cognito-idp.ap-south-1.amazonaws.com https://cognito-idp.ap-northeast-2.amazonaws.com https://cognito-idp.eu-west-3.amazonaws.com https://cognito-idp.sa-east-1.amazonaws.com https://cognito-idp.us-west-1.amazonaws.com https://cognito-idp.ca-central-1.amazonaws.com https://cognito-idp.eu-south-1.amazonaws.com https://cognito-idp.me-south-1.amazonaws.com https://es.us-west-2.amazonaws.com https://es.us-east-1.amazonaws.com https://es.us-east-2.amazonaws.com https://es.eu-west-1.amazonaws.com https://es.eu-west-2.amazonaws.com https://es.ap-southeast-2.amazonaws.com https://es.ap-northeast-1.amazonaws.com https://es.eu-central-1.amazonaws.com https://es.ap-southeast-1.amazonaws.com https://es.ap-south-1.amazonaws.com https://es.ap-northeast-2.amazonaws.com https://es.eu-north-1.amazonaws.com https://es.eu-west-3.amazonaws.com https://es.sa-east-1.amazonaws.com https://es.us-west-1.amazonaws.com https://es.ca-central-1.amazonaws.com https://es.eu-south-1.amazonaws.com https://es.me-south-1.amazonaws.com https://es.ap-east-1.amazonaws.com https://es.ap-northeast-3.amazonaws.com https://es.ap-southeast-3.amazonaws.com https://es.af-south-1.amazonaws.com https://dynamodb.us-west-2.amazonaws.com https://dynamodb.us-east-1.amazonaws.com https://dynamodb.us-east-2.amazonaws.com https://dynamodb.eu-west-1.amazonaws.com https://dynamodb.eu-west-2.amazonaws.com https://dynamodb.ap-southeast-2.amazonaws.com https://dynamodb.ap-northeast-1.amazonaws.com https://dynamodb.eu-central-1.amazonaws.com https://dynamodb.ap-southeast-1.amazonaws.com https://dynamodb.ap-south-1.amazonaws.com https://dynamodb.ap-northeast-2.amazonaws.com https://dynamodb.eu-north-1.amazonaws.com https://dynamodb.eu-west-3.amazonaws.com https://dynamodb.sa-east-1.amazonaws.com https://dynamodb.us-west-1.amazonaws.com https://dynamodb.ca-central-1.amazonaws.com https://dynamodb.eu-south-1.amazonaws.com https://dynamodb.me-south-1.amazonaws.com https://dynamodb.ap-east-1.amazonaws.com https://dynamodb.ap-northeast-3.amazonaws.com https://dynamodb.ap-southeast-3.amazonaws.com https://dynamodb.af-south-1.amazonaws.com https://rds.us-west-2.amazonaws.com https://rds.us-east-1.amazonaws.com https://rds.us-east-2.amazonaws.com https://rds.eu-west-1.amazonaws.com https://rds.eu-west-2.amazonaws.com https://rds.ap-southeast-2.amazonaws.com https://rds.ap-northeast-1.amazonaws.com https://rds.eu-central-1.amazonaws.com https://rds.ap-southeast-1.amazonaws.com https://rds.ap-south-1.amazonaws.com https://rds.ap-northeast-2.amazonaws.com https://rds.eu-north-1.amazonaws.com https://rds.eu-west-3.amazonaws.com https://rds.sa-east-1.amazonaws.com https://rds.us-west-1.amazonaws.com https://rds.ca-central-1.amazonaws.com https://rds.eu-south-1.amazonaws.com https://rds.me-south-1.amazonaws.com https://rds.ap-east-1.amazonaws.com https://rds.ap-northeast-3.amazonaws.com https://rds.ap-southeast-3.amazonaws.com https://rds.af-south-1.amazonaws.com https://secretsmanager.us-west-2.amazonaws.com https://secretsmanager.us-east-1.amazonaws.com https://secretsmanager.us-east-2.amazonaws.com https://secretsmanager.eu-west-1.amazonaws.com https://secretsmanager.eu-west-2.amazonaws.com https://secretsmanager.ap-southeast-2.amazonaws.com https://secretsmanager.ap-northeast-1.amazonaws.com https://secretsmanager.eu-central-1.amazonaws.com ```
0
answers
0
votes
42
views
asked a month ago

How to Set Cognito preferred_username for User When email, phone, and preferred_username Can All Be Used as Aliases?

I am using Cognito User Pools for a ReactJS SPA via amazon-cognito-identity-js (https://www.npmjs.com/package/amazon-cognito-identity-js). **Intention: I would like to give all users in a user pool the flexibility to log in through aliases for (1) Email, (2) Phone, and (3) Preferred Username. Ideally, they would have the choice to use all three--granted that their email address and phone number are verified.** I have gone in circles looking at various AWS docs. I searched for code examples of how someone would do this. Handling the ``preferred_username`` is the most concerning aspect, when email address and phone number can also be used as aliases too. I am not sure of the approach I have derived, so I wanted to see if someone could weigh in. I have been referencing the following: * [https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases-settings-option-2] (User Pool Attributes - Amazon Cognito) * [https://maurocanuto.medium.com/aws-cognito-3-things-you-need-to-know-before-creating-a-user-pool-35abdb999c08] (AWS Cognito: 3 things you need to know before creating a User Pool by Mauro Canuto) * [https://stackoverflow.com/questions/63171750/cognito-and-java-username-cannot-be-of-email-format-since-user-pool-is-configu] (StackOverflow: Cognito and Java - Username cannot be of email format since user pool is configured for email alias) * [https://stackoverflow.com/questions/42515859/aws-cognito-workflow-using-email-alias-for-primary-username] (StackOverflow: AWS Cognito Workflow: Using email alias for primary username) I wanted to capture all user data during the Registration of a user account, using the `signUp` method in amazon-cognito-identity-js. > `signUp(username: string, password: string, userAttributes: CognitoUserAttribute[], validationData: CognitoUserAttribute[], callback: NodeCallback<Error, ISignUpResult>, clientMetadata?: ClientMetadata): void` However, according to the AWS Cognito User Pool Attributes link above.... > If you select `preferred_username` as an alias, your user can provide the value only when they confirm an account. They can't provide the value during registration. `` Separately, if you select **preferred_username**, **verified email address**, and **verified phone number** options for aliases....and send the user's email address as the first parameter to `signUp`, it results in an `HTTP 400: InvalidParameterException: Username cannot be of email format, since user pool is configured for email alias.` So, the `signUp` method is expecting a username value (not email) when email address is selected as an alias. The same is true for phone number if phone number is selected as an alias. This makes sense, as both attributes are being used as aliases and must be verified, so both should have unique values (vs two email addresses or two phone numbers). When email is not selected as an alias and the email address value is sent as the username (first) parameter to the `signUp` method call, Cognito assigns a UUID (format: {d}8-{d}4-{d}4-{d}4-{d}12) for the username. The AWS docs (first link above, Option 2, under Using aliases to simplify user sign-up and sign-in) specifically state that when an email address is supplied as the username param, the email attribute is populated with this value....and a similar process is true for the phone_number attribute. I have checked and a user can log in using this auto-generated UUID as the username value. So, when all three aliases are allowed and the `signUp` method is used: * I cannot supply the `preferred_username` value in the attributes list (3rd parameter) during the registration. * I cannot use an email address or phone number as the username value (due to the 400 above--it is similar for phone, just sub "email" in the error with "phone number") * I can set the user's email address and phone number values using the attribute list. * I can specify a preferred username as the first parameter as long as it is not in the format of an email or a phone number. * Once the user confirms their account by using the confirmation code sent in an email to verify their email address, I can then set the `preferred_username` value via an attributes list supplied to the `CognitorUser.updateAttributes` method. **Possible Approach: I can have a process of gathering all user info minus preferred username --> register via `signUp` invocation --> prompt the user to enter the confirmation code they are sent via email --> with the account now being confirmed, prompt the user to enter their preferred username --> save the `preferred_username` value using the `CognitorUser.updateAttributes` method. During the registration by using the `signUp` method, I must supply a username as the first parameter. I could prompt the user earlier in the process to provide their preferred username and include that as the username parameter as well as save it post-confirmation as the `preferred_username`. Later, if they want to change their username, the `preferred_username` could be updated with the new value, while the original `username` value stays unchanged. This would mean a disparity between those values at this point, and an account can be logged into via two different usernames (the `username` and the `preferred_username`). But does it matter? Or should I use CryptoJS and generate a "random" UUID for the username value when registering via `signUp`? As mentioned above, the UUID can be used to log in as well.** Is this a good approach? Or am I missing something or adding unneeded complexity?[]()
0
answers
0
votes
17
views
asked 2 months ago