amplify-android icon indicating copy to clipboard operation
amplify-android copied to clipboard

Amplify.Auth UserAttributeKeys different from iOS

Open lawmicha opened this issue 4 years ago • 9 comments

On Android, user attributes map exactly to cognito user attributes, while iOS's user attributes is missing a few, specifically zoneinfo, website, updated_at, profile.

Should iOS have these attributes for parity or are these too specific for the Amplify layer? the solution on iOS is to pass .unknown("zoneinfo"). If Cognito introduces a new user attribute, is there a way to pass that attribute key name on Android? I see there's a custom one on Android as well. On iOS cognito plugin there is custom logic that prepends the custom: prefix to the passed in .custom([value]) case so it is sent to cognito as custom:[value]. is this the same behavior on Android?

Related issue on iOS: https://github.com/aws-amplify/amplify-ios/issues/751 Cognito docs: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html

lawmicha avatar Sep 02 '20 17:09 lawmicha

@TrekSoft , can we have your input on this?

raphkim avatar Sep 02 '20 20:09 raphkim

None of those four attributes are specific to Cognito so I think it's worth keeping them. They could be named more clearly but given the benefit of using consistent terminology with what people expect from the past, I think it's worth keeping them named as is too. As far as what happens if Cognito introduces a new user attribute, I'm not sure, that may be worth investigating.

TrekSoft avatar Sep 02 '20 20:09 TrekSoft

Android currently doesn't appear to be appending any prefix to the custom attribute key. Will this disparity cause any issue? Does Cognito treat an attribute prepended with custom: differently than the others?

raphkim avatar Sep 04 '20 12:09 raphkim

@lawmicha should this be transferred to amplify-ios?

Jordan-Nelson avatar May 27 '21 14:05 Jordan-Nelson

Android currently doesn't appear to be appending any prefix to the custom attribute key. Will this disparity cause any issue? Does Cognito treat an attribute prepended with custom: differently than the others?

yes this would cause an issue and cognito treats them differently: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes custom attributes require "custom:" prefix to distinguish them from standard attributes

As @TrekSoft mentioned there is an API enum case disparity. iOS should probably add those missing cases and make sure it is an additive change to the developer's perspective

@raphkim described a plugin implementation disparity. Android should probably update plugin implementation to prepend "custom:" otherwise it wouldn't be possible to use Custom Attributes via Cognito. iOS has both .unknown and .custom cases on the public enum. unknown is used to pass any string and is used as is, custom is used to pass any string, and has the "custom:" prepended

lawmicha avatar May 27 '21 15:05 lawmicha

@lawmicha should this be transferred to amplify-ios?

We should keep this issue to track Android's support for .custom and .unknown.

iOS should track adding the missing enum cases: https://github.com/aws-amplify/amplify-ios/issues/1248

Flutter should implement against the workaround using iOS's unknown case: https://github.com/aws-amplify/amplify-flutter/issues/598#issuecomment-849715738

lawmicha avatar May 27 '21 15:05 lawmicha

Android should probably update plugin implementation to prepend "custom:" otherwise it wouldn't be possible to use Custom Attributes via Cognito

For now, the workaround would be to use custom("custom:" + attribute) for the custom attribute key use-case and I suspect that there are already some customers who are doing this.

I imagine it will be a breaking change for them if we introduce the new behavior.

raphkim avatar May 27 '21 16:05 raphkim

For now, the workaround would be to use custom("custom:" + attribute) for the custom attribute key use-case and I suspect that there are already some customers who are doing this.

I'm going to have to do exactly that. Is there a better choice?

GSala avatar Sep 22 '21 14:09 GSala

None as of now. Please use the workaround if that fits your use case.

div5yesh avatar Jan 29 '22 00:01 div5yesh

If upgrading is an option for you to our V2 version of Amplify Android library I would recommend doing so as we are now using AWSCognitoAuthUpdateUserAttributesOptions.metadata where you can store your userattributes in a map. Thank you.

gpanshu avatar Dec 29 '22 18:12 gpanshu

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

github-actions[bot] avatar Dec 29 '22 18:12 github-actions[bot]