search

aws-amplify / amplify-cli

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development.
Apache License 2.0
2.81k stars 819 forks source link

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

Closed ericclemmons closed 2 years ago

ericclemmons commented 4 years ago

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 (https://github.com/aws-amplify/amplify-js/issues/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:

p

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 commented 4 years ago

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

Bulletninja commented 4 years ago

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 commented 3 years ago

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

https://github.com/aws-amplify/amplify-js/issues/7482

hkjpotato commented 3 years ago

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.

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

https://github.com/aws-amplify/amplify-ui/pull/59#discussion_r663219536

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 commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

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"
],