I am able to generate the token for users and successfully start the SinchClient by following this tutorial. Now, next step is to send and receive messages. Now, how do I recognize users? Since I am using authentication token to start the SinchCleint and not a particular username when starting a SincClient, then how can I send messages to a particular user?
As you recognize Sinch doesn't have the info about your users, you only start the client with a unique token. Sinch is built on the assumption that you have a user database and social network of you own, and the sinch client "address" to send messages to is something you keep track of. Does that make sense?
Related
Trying to send out chat message from Bot with sender as a current logged in user. I am able to implement this with graph api using On Behalf of flow. However the API is still in Beta and don't think we can use it in production setting.
https://learn.microsoft.com/en-us/graph/api/chat-post-message?view=graph-rest-beta&tabs=http
Is there a different way? Can we use ConnectorClient? Tried this, but the chat message is sent by the bot instead of the current logged in user. I am not able to create user token with botframework.com. It is always bot or the registered app.
Do anyone know if there is a way to accomplish this avoiding the graph beta api?
We currently have a solution where we implement 2FA ourselves over Twilio Programmable SMS.
We're also using Twilio Verify for Payment PSD2 authorization.
We're now looking to migrate everything to Authy to make use of the Authy app and I have the following questions that I'm hoping you can help me with.
User Migration. I understand in authy, users need to be registered to our application. How can I register all our current users? Is there any way to bulk upload them, or do I have to write a script that calls the API to register them one by one?
User Number phone update. Sometimes our users will update their phone or email in our system. If that happens, how do I update that info in Authy? I couldn't find anything in the docs about that. Do I need to call the api to remove the user and readd with the new info?
Migrating from Verify PSD2 to Authy PSD2. Is the implementation very different? Is there any sample I can look through, as the documentation seems to mainly be talking about QR codes, while what we want to do, is to send it over SMS or Authy depending on the user's choice.
Thanks for your help
Sam
Twilio developer evangelist here.
You will need to write a script to register your users. When you have registered a user, you will receive an authy_id for the user, which you will need to store with your user record.
If a user updates their phone number then you should update the Authy user. To do so, you will want to delete the old user and re-register with the new phone number. You will then receive a new authy_id and you should re-confirm the user can authenticate by challenging them for a new code before you complete the update. If the user updates their email then you can do the same process of deleting and creating a new user though you should receive the same authy_id back if the phone number hasn't changed (though this will add the email address to Authy's representation of the user).
Check the documentation on PSD2 compliant authentication with Authy here. If you are sending SMS messages, then you should set the action and action_message parameters, which tie the message to the authentication. For the app based authentications you can do it via Push Notifications (in which you can include transaction details in the push). If you don't want to implement push, then you do need to get your user to scan a QR code in order to tie the transaction to the authentication (the regular code generated by the app is not connected to a transaction, so is ineligible for PSD2 authentication).
Let me know if this helps at all.
I developped a mobile app using our backend to register and verify users using Authy.
This is done by the backend in 3 steps:
1/ The app requests the backend to register the user.
The backend calls https://api.authy.com/protected/json/users/new (email, cellphone, countrycode). It provides back the userId later used.
2/ The app requests the backend to send a sms code the user.
The backend calls https://api.authy.com/protected/json/sms/{1}?locale={2}{3}" (userId, language, force)
3/ The user now receives the SMS. He fills it in the mobile app, which eventually is sent to the backend for verification.
The backend calls https://api.authy.com/protected/json/verify/{1}/{2}{3}" (token, userId, force)
I wanted to use Automatic SMS Verification with the SMS Retriever API in my mobile app (https://developers.google.com/identity/sms-retriever/overview) to avoid the hassle for the user to enter his verification code.
It requres to set up a hash in the verification code, but unfortunately I don't seem to have any control on what Authy generates.
Am I missing something here to get it work?
Rgds
R.
No, you just can't affect the text in Authy's SMS. So, for now, it looks like we can't support retriever API.
I've done lots of research on this from Firebase to App delegate but I don't understand a lot. I'm trying to send notifications to the user when someone else has posted something in my app - like on Instagram or social media post notifications. Can someone please point me in the right direction for how to do this? Thanks a lot in advance!
Overview
If you have setup your iOS app for Firebase Cloud Messaging (FCM), when the user first opens your app, the apps talks to the google servers and generated a token specific to that device.
What is a token?
The token is like a device identifier. You use that token to tell firebase which exact device you want it to send the notification to. (The token changes on uninstalling and reinstalling the app and may even on a restore).
On the backend
Now, you have to configure your app to send that token to your backend and store it as one of the tokens for the user currently logged in. (This should happen every time they login from that device, and you should remove that token from the server when the user logs out).
Whenever you need to send out a notification, you'll have to make a POST request to the FCM server. This POST request will contain the device token and the content of the notification, along with other authorization info. Detailed instructions are provided at
Send a Notification Message
I've set up Firebase to send push notifications to users of my app. However, I'm not sure what's best practice regarding user-to-user communication, such as chat clients. Should I get the device token at each startup of the app and use that for sending, or should I create a new topic for each "chatroom" that both parties are required to subscribe to? For instance when accepting a chat request.
If the first option is the best, how does this work? If the device is assigned a new token upon app startup, how can I be sure a given ID points to a specific device? The whole concept seems fragile - but could someone guide me to the most efficient solution?
I'm only looking to send chat messages / chat invites with push
Depending on the size and the privacy of the chatroom you can choose between using:
topics made for big groups, and without protections on joining / leaving
device tokens that you need to store in your server implementation.
On the plus side they allow you to control the who is receiving the
messages, and to send messages to individual device.
The device token does not change every startup.
It is created when the application is launched for the first time, and can be updated in special cases. When the token change (again, this is rare) the FirebaseInstanceIdService.onTokenRefresh() callback is called.
In a generic chat application you might want to:
first authenticate the user with your login system
upload to your server the mapping user-id > device-token
send messages to the users via the FCM server-side APIs.
Update to address one of the comments:
The server-side API allows to send the same message to multiple tokens in the same HTTP request. See registration_ids in https://firebase.google.com/docs/cloud-messaging/http-server-ref#downstream-http-messages-json
You should not use the server-side API in the client, because that would require you to add the API-KEY in the application which is a security issue (people could decompile the app and read the key)
The storage structure is up to you. For user-id > multiple-device-tokens a dictionary could work.
If the token are non reusable. So it's safe to send messages to expired token.
Token generation requires internet connectivity, so it could take some time.
To handle token after user registration see this question:
How to launch FCM ID Service only after a particular activity is triggered?