Aws Cognito - Social Sign Up, change mapping value of username attribute - react-native

If i try to map email to username attribute. I can't do that.
I get Invalid attribute mapping. On documentation I found this note.
aws documentation
Can I map email to Username attribute using react-native in any other way? Is it still not possible?

Related

What is proper username in Cognito User Pool?

I need to check that a proper username is entered in the custom signin form on my web site to pass it to Auth.signUp method of aws-amplify.
Things like minimum/maximum number of characters and allowed characters.
Documentation at this link does not help, please point me to a correct page, thank you!
See AWS SDK for validation rules.
The username for the user. Must be unique within the user pool. Must
be a UTF-8 string between 1 and 128 characters. After the user is
created, the username can't be changed.
https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-cognito-identity-provider/interfaces/admincreateusercommandinput.html
Not perhaps a perfect description but has at least the minimum and maximum character count.
Edit: Cognito API reference reveals that regex pattern for username validation is: [\p{L}\p{M}\p{S}\p{N}\p{P}]+
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html
BTW, username cannot be changed after creation so perhaps you want to use preferred_username attribute to store the username which a user submits in sign in form (and make back-end to generate a value for username automatically (uuid for example)).
The document behind the link states:
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.

AWS Cognito Amplify + Angular : Login using Username/instead email-id

I am creating a custom Login, registration form in angular. I want to login using username, not the email id , is there a way to do so?
Code reference would help!
Yes, this can be done .
The setting needs to be done while creating a userPool in aws Cognito .
In the attributes tab , One needs to check the checkboxes containing
the following.
Also allow sign in with verified email address
Also allow sign in with preferred username (a username that your
users can change).
This way , a user can sign in by both email address and the user name .

Check if user existed in cognito as federated user by using only email/username

I'm having trouble implementing a feature where I need check if a user does not exist or is existing in cognito but as federated user. The prior is done without trouble but I'm stuck on the latter without any clue. I went through the cognito and amplify documents but couldn't find any clue. Could there be a work-around or a function that I don't know about, any suggest is welcomed.
You can create a mutable custom user attribute on Cognito such as isFederatedUser and set this on user during user creation.
If this is not possible, you can call list-users and filter the identities attribute.

How can I access my User custom properties defined in my AWS Cognito User Pools?

I added a few custom properties in the User configuration off my AWS Cognito User Pool. I have my app in objective-c similar to the sample project CognitoYourUserPoolsSample. Everything works fine and I can sign-in/sign-up without any problem.
Though, I don't know how to access and set all the User custom attributes that I added in the User Pool config. I can access the default attributes values from the response object AWSCognitoIdentityProviderGetUserResponse for example. They are stored in the _userAttributes property (e.g. phone, email, etc.).
My questions are:
Where are the custom attributes stored?
What is the proper way to set them during sign-up?
I get the following error when I try to sign-up with custom attributes using the same approach as the default attributes:
// add custom attributes
AWSCognitoIdentityUserAttributeType * subscriptionType = [AWSCognitoIdentityUserAttributeType new];
subscriptionType.name = #"subscriptionType";
subscriptionType.value = #"Premium";
[attributes addObject:subscriptionType];
Here is the error I get.
responseObjectForResponse:originalRequest:currentRequest:data:error:] | Response body:
{"__type":"NotAuthorizedException","message":"A client attempted to write unauthorized attribute"}
Thanks!
To answer your questions:
Custom attributes are stored internally by Cognito, custom attributes can be seen from the response of a DescribeUserPool call.
They should be set on pool creation from the Cognito console. They are not allowed to be set from a client, which is why you saw issues.
Thanks
As I found in the issue:
Signup with custom attributes in Cognito user pools
to set the value for custom attribute you must set a write permissions for it.
Open Amazon Cognito Console -> YourPool -> General Settings -> App Clients -> Show Details -> Set attribute read and write permissions and activate checkboxes for your custom attributes.
Also in code attribute name should contain a prefix 'custom:'
i.e. subscriptionType.name = #"custom:subscriptionType"; and those values are shown in AWS console.

Attaching additional info to a Google user

Is it possible to add additional info to a Google user, during creation, on a Google Domain?
We have a range of users, that we identify by their email ("username#domain.com"). Some of the users gets to pick a new email, like with their initials, instead of the autogenerated username.
This causes a issue, since we are using a webservice (that we have no controll over), this webservice provides only the users real name, and then their autogenerated username, but not "custom" email with for example the users initials.
So when the user from google comes with his login info, I cant match that user with the userdata from the webservice.
If it was possible to attach the autogenerated username to the google user, it could be matched that way. But i havent been able to find anything about adding custom info like this, to a Google Domain user.
We solved this issue, by adding an alternative email with the autogenerated username + google domain on creation of the Google user.
We then checked the email of the user trying to log in, and if it didnt match, we then checked his alternative email for matches.