amplify-android
amplify-android copied to clipboard
Amplify.Auth UserAttributeKeys different from iOS
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
@TrekSoft , can we have your input on this?
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.
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?
@lawmicha should this be transferred to amplify-ios?
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 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
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.
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?
None as of now. Please use the workaround if that fits your use case.
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.
⚠️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.