Add usernameAttributes (e.g. "email", "phone") to aws-exports.js

[ericclemmons]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Customers run amplify add auth (aws-amplify/amplify-js#3451) with email instead of username, then use Amplify's UI components (e.g. withAuthenticator(App)) in their app, but the UI doesn't reflect their configuration:

They have to carefully read the docs to learn they need to use usernameAttributes to get the two in sync:

https://aws-amplify.github.io/docs/js/react#sign-upin-with-emailphone-number

(This also caught me off-guard the first time I've used Amplify!)

Describe the solution you'd like

aws-exports.js contains the auth value so that the UI can automatically reflect it.

Describe alternatives you've considered

Change the upcoming UI components to not have a default at all (e.g. username) and require configuration to show it at all:

https://aws-amplify.github.io/docs/js/react#sign-upin-with-emailphone-number

[ericclemmons]

Is it possible to use https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_DescribeUserPool.html to do this work?

[Bulletninja]

https://aws-amplify.github.io/docs/js/react#sign-upin-with-emailphone-number

Is there a way to search for this link? At some point links from docs.amplify.aws broke and has not been fixed...

[ericclemmons]

Related, there may be other fields configured via amplify add auth that should be exported automatically:

aws-amplify/amplify-js#7482

[hkjpotato]

Just some thoughts: briefly look into this with my limit knowledge about aws-export.js, I have some concerns of putting the usernameAttributes in this config file.

• Do we have some guidance/agreement on what should/should not be inside aws-export.js? From my current understanding it is more for non-UI, backend meta data such as user-pool-id. Generally they are unchangeable, basic endpoint info, not for configuration/customization.
• Do we have any existing examples for UI which is configured/driven by aws-export.js? I could not find an example of ui-components reading this backend config file to determine the UI details.

---

My concern of using aws-export.js to configure the UI are

1. Should we use a static config file to drive our UI behavior? How do we ensure this file is always updated and in sync for different use cases?

   • e.g, if a user previously used withAuthenticator HOC to read from this file to render the simple UI. Later they decide to write their own overriding props, or even their own customized components/fields, will this config file still be valid? Which configuration should be the single source of truth for the UI?

2. If we decide to use a static config file to drive the UI, is aws-export.js a good one or should we have a separate config file just for UI.

[ericclemmons]

Another example that came up in today's "Amplify with Friends" was with custom sign-up attributes, like Preferred Username.

When these are configured, the UI has no idea about it. So it means the Authenticator doesn't work out-of-the-box – customers have to immediately customize form fields & settings even though they already did that.

[swaminator]

The UI team is mocking out the changes required in the exports file. For example, something like this would be ideal:

    "passwordPolicyCharacters": [
        "Requires Lowercase",
        "Requires Numbers",
        "Requires Symbols",
        "Requires Uppercase"
    ],
    "requiredAttributes": [
        "phone_number"
    ],

[ericclemmons]

As @swaminator mentioned, we discovered an example of additional information that the backend gets configured with that the UI could use to enhance the experience:

aws-amplify/amplify-ui#59 (comment)

To keep a running tally:

1. Login Mechanism(s)

   Until this is added, the Authenticator needs to be manually configured to show the right Email/Phone/Username label/input.

   Once this is added, the Authenticator would be zero-config. Especially if this includes social providers like Google, Facebook, etc.

2. Custom & Required Attributes

   Admin UI (today) adds "Preferred Username" by default. Customers have to manually add fields/validation/signUp functionality to support these.

   If these were provided, the Authenticator fields could be rendered & validated by default.

3. Password policies

   End-users who try to create an account have no UI to guide them on password requirements. The Authenticator's validation would have to be heavily augmented by every customer implementation to match their policy. (If they're even aware of what the rules are, since these are often set by default)

   If this were provided via aws-exports, the UI or underlying Auth.signUp functionality can validate before making an API call.

[kaustavghosh06]

Can this information be instead fetched from the Cognito control-plane instead of relying on the aws_exports.js file for the source of truth for these resource configurations?

[ericclemmons]

@kaustavghosh06 We researched that last year, but IIRC ran into two issues:

1. An unauthenticated end-user wasn't able to fetch user pool configuration at run-time.
2. Nor did we want to send a request for every end-user to fetch these details.

I'm open to suggestions on the best way to make the Authenticator zero-config with their configured backend 🙏

[josefaidt]

Closing as this has since been added to the generated aws-exports.js file. For example if I create an auth resource using "Phone number" as the login mechanism we see the following is generated:

"aws_cognito_username_attributes": [
    "PHONE_NUMBER"
],