Allow user to choose how they receive forgot password code - amazon-cognito

Tried searching for this in Amazon's docs but couldn't come up with anything.
Assuming that both email and phone number are checked in the verification section of the user pool. If the client app wants to allow the user to choose how they receive the code (assuming they've forgotten their password) - how do we get Cognito to handle that? Is there a way of getting the forgotPassword method to select a route (email or SMS)?
From some early testing, it seems like it always goes one route if both are available. I do see that Amazon themselves have made this available on their site though, so hoping that it should be possible?
For this example, we can assume that we've got a verified email address and phone number for that user.

I am on the Cognito team. Currently the behavior is that if both phone number and email are verified, the code goes to the phone, hence phone number is given preference and there is no way to select where the code actually goes. However, we have heard this request in the past and I will add a +1 to the feature request on your behalf.

Related

Customize Firebase / Google Identity Platform Multifactor Authentication Confirmation Email

I have successfully and deceivingly easily added Firebase authentication for my web ap. I've found during my work that it's actually just a wrapper over the identity platform product from GCP. I've found this out while working on adding two factor authentication via phone for the app as well.
Everything works fine for the amount of complexity 2fa brings.
The problem I am now facing is that every time I enroll a user to the second factor, they get a horrendous automatically generated email which I just can't seem to understand where to change.
I know that transactional emails are a bit unwieldy in Firebase, so I fear the worse on customization, which is why I am asking:
Where do you change, or disable that email? I am already notifying the user their phone was validated and they just got the SMS on their phone, there is no need for another ugly notification.
That said, the documentation does say an email will be delivered upon running the multiFactoruser.enroll method, but not much else.
I've also found that the identity platform allows for programmatic enrollment via the admin SDK which is I guess my next plan if the email cannot be disabled.
This seems straightforward enough, but I'm wondering if it will also send a validation SMS or that is simply it, if the user adds a wrong phone, they will then be locked out of their account.

Signing up users using phone number react-native-firebase

I am working on an application that will sign up users based on their phone numbers. Everywhere I have read, there are articles regarding signing in users using their phone number. While researching for this I landed on a stackoverflow article itself that mentioned that the signInWithPhoneNumber() article will work for sign up when queried for first time, and will be used for sign in once the user is created as in this article What will happen if I sign in user using phone number without user creation in firebase?.
Going by this article, I wrote the following code to achieve my purpose
import auth from "#react-native-firebase/auth";
console.log("going to sign up with", numberToSend);
// numberToSned is the input number to which the message has to be sent
const confirmation = await auth().signInWithPhoneNumber(numberToSend);
I also set up a dummy number to test the feature.
But whenever this request is made my application shuts down by itself
Also I do not get any error on the console regarding this
So I wanted to ask is their a way to sign up users using their phone number in firebase with react-native?
As the link you describe (but didn't share) says: Firebase makes no distinction between signing up with a phone number or signing in with a phone number. The code for both cases is exactly the same, as shown in the documentation on Firebase phone authentication.

Identify unique user in Dialogflow V1

So I am testing out Dialogflow and one of the first questions I have is: how does my bot know who it is talking to? I need to identify a user and keep that information for as long as I can. The basic scenario being:
User starts his/her first conversation.
Chatbot send a fulfillment request to the server trying to match a user within its own database.
The user is found, the information (as a JWT or some other token) is sent back to Dialogflow and stored there for further communication. In reality, this part would involve asking for user email, sending a verification code to that email and then verifying the user with the code.
User then starts chatting with a bot and all fulfillment requests get the unique token stored for this very user, so that my REST API knows which user is being served with the response.
Couldn't find anything about it in the docs (maybe I am looking in the wrong places).
There will be several integrations, like Messenger, Viber, Telegram. I dunno, maybe those APIs add some unique information on the user?...
Thanks for the help!
Sorry, I know it's been a while, but maybe this will help someone else.
The right solution here is a user id, not a session id. A user id is provided by the chat platform (Facebook, Slack etc) and is consistent across sessions for the same user.
To get the user id, go to the Fulfillment tab, enable the editor and use a function like so:
let r = request.body.originalDetectIntentRequest
//this makes sure that you're on an integration
if (r["source"]){
return r.payload.data.sender.id;
}
To tie together ids from different platforms, you probably have to have some kind of log-in process every time you encounter a new id on a platform.
Pop,
Sessions are built in already into DialogFlow requests to your fulfilment service, if you check the payload you will find a sessionId, it remains the same for the same client until it expires.
However if you want to identify the user from any of the clients that you can connect to DialogFlow like Messenger then from the same request payload to you you will notice that there is an object named originalRequest that is only available when requests are coming from those clients.
You can personalize those users response eg using their FB firstname in a message to them.

Logic Behind Social Login

I have created a nice little login script for my website that lets users login with Facebook or Google at the moment.
What I am trying to do is set some checks to make sure that duplicates do not appear in the database.
Here are some scenarios I have covered :
Login with Google/Facebook account and I have already registered this account, This will log the user straight in as they have already linked this account.
User has already registered with Google account, yet clicks Facebook because they cannot remember which account they used. This will alert the user that the email address returned from Facebook has already been registered with a Google account. This will enable them to click on Facebook to Login ??? NOT SURE ON THIS LOGIC AT THE MOMENT ???
User clicks on Google/Facebook to login, yet the email address returned is a user that went through the manual registration. This will alert the user that the social account they are trying to login with will require a password.
What I am thinking of doing is allowing users to LINK ACCOUNT so that the alerting process does not happen because I can link my facebook account to my google account through my website, and vice versa etc etc.
What I am asking :
Are there any other checks I may be missing? Is this logic sound? Is there anything I am doing which makes you question the login process??
Basically asking logic advice on this one.
Well congratulations! You're almost on the right track. Let's breakdown your situation here.
Ideal Situation
1. Registered on your site
2. Log in with Google
3. Log in with Facebook
Now, let's take the common denominator here, I mean the primary key. I am guessing in your case it should be the email address.
Actual Process Flow
1. User registers. You save the email address
Or,
2. User registers with Google/Facebook and you save the email address.
Login Procedure
1. You receive the email address either from direct login/facebook/google.
2. You match it against your table
3. On positive match, you link this social login to an existing account
If,
4. It is not a positive match then you accept whatever data you receive and then forward
and then pass on to the registration page.
Hope this helps! Let me know if you want to know anything else.
Cheers!

Mailchimp API (v1.3): addresses added with listSubscribe() don't appear in dashboard

I'm using Mailchimp's API (v1.3) to add email addresses to a subscriber list on one of our sites. Obviously, I'm using listSubscribe() and everything is working fine, for the most part (read: API call returns true, all of the data I'm sending to Mailchimp gets added/updated correctly).
The problem, however, is that whenever a new address is added, the things that are normally supposed to happen (in particular: email notifications to list manager, addresses showing up in the dashboard list status stream) aren't happening.
I've looked around for quite a bit and haven't found anyone with the same issue. Any ideas?
The default action of listSubscribe to add a subscriber is opt-in. This means that when you submit a listSubscribe the subscribed user will get an email asking to confirm their opt-in.
If the user does not follow the link in the email then they will not appear in the dashboard.
You can bypass this by using:
'double_optin' => FALSE,
http://apidocs.mailchimp.com/api/1.3/listsubscribe.func.php
However this is only recommended for very occasional circumstances (essentially where you are handling the opt-in).
In my case I am not activating a user account until they verify their email address. If let the opt-in email be sent then the user is going to get a number of emails from my web app. I'm being very careful to make sure that they're verifying their subscription and all subscription stuff is being processed by the web app (eg a user unsubscribes within the web app, not via MailChimp).
I talked to the Mailchimp support, and they said those actions won't happen using their public API; there is no way to trigger them.