I am fetching Id and token using InstanceId and store somewhere in my app. After reinstalling the app, I got new token and id. When I'm using old token and id for sending message through gcm, it shows success. But if I use only token for sending message, then it shows canonical. Can someone explain this in details?
example -> result :
1) "oldId:oldToken" -> success
2) "oldToken" -> success and canonical with new token
3) "newId:newToken" -> success
4) "newToken" -> success
I have issue in 1st example: Why is that not showing canonical and new token?
Check link: click here
Be noted that Canonical ID is returned in the response when you send a message from your server to google's gcm server. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
From this thread:
When you receive a canonical registration ID in the response from Google, the message was accepted by the GCM server and the GCM server would attempt to deliver it to the device. Whether it is actually sent to the device depends on whether the device is available (i.e. connected to the internet). So if your server sends a GCM message to both the old ID and the new ID, the device will probably get two messages.
A canonical registration ID is defined to be the ID of the last registration requested by your application. This is the ID that the server should use when sending messages to the device. If later on you try to send a message using a different registration ID, GCM will process the request as usual, but it will include the canonical registration ID in the registration_id field of the response. Make sure to replace the registration ID stored in your server with this canonical ID.
Old registration IDs can remain active for a while. However Google tells you that you need to update your regid for a particular device/app combination by means of the canonical ID in the response to your sent message.
Check this related SO question:
How to get Canonical ID from GCM
Do old GCM tokens live on even after an uninstall?
Related
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.
I have my app running on a Nexus 5 (Marshmallow) which has 2 active registration ids. Just want to know if that is normal by GCM behavior?
Here's how it's causing me trouble:
Android M has come up with Group permissions - which means the user chooses whether or not he wants the app to have access to his device identifiers (Android ID). Let's assume he denies it and I can't identify the device. The way my app functions is that a user can log in from multiple devices, all of which remain in sync. Because a user can be on mulitple devices, I must handle multiple registration IDs to send push messages (and I cant be sure of the number of devices the user is on, as they can deny providing the device identifiers). This means that I cant delete/update any registration ids on the server side, but only send every push message to all recorded IDs against a user, in the hope that all the devices on which that particular user is signed in will receive the messages.
Because I have a device which has two active registration IDs, I am getting 2 notifications for everything.
On the client end, we were noticing frequent changes in the Registration IDs, we have a class that keeps generating registration ids and updating the server.
Having multiple registration Ids can be a bug in the client app (which you have to deal with).
And the only way to ensure that there will only be one notification being sent per device is to implement canonical IDs on the server side. It is included in the webservice response as "canonical_ids".
Canonical IDs
If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.
Here is a related issue
android GCM get original id of canonical id which tackles how canonical ids work in the actual code
I have my push notifications working fine for my mobile Android app
through GCM, but have a specific question about my environment. My
app would like to be able to receive pushes potentially from more than 100
senders (servers) and the comments (see below) in the documentation confuse me.
Basically consider this situation...
I registered my project on the Google Dev Console and obtained my
project number (aka - sender ID) and my server key. For the latter
I did NOT specify specific IP addrs.. just left the field blank.
My app boots and does a "register" with this one single sender ID
and receives the registration key.
I send this registration key to my 500 "source" servers, and these servers also
have the SAME server key.
So again to summarize... my 500 servers that want to send pushes to the phone would
ALL be using the SAME server key and the SAME registration ID.
Simple question.. is this allowed? If so, what do all the restriction warnings mean
(below) from the GCM docs.... and if not allowed, I want to understand technically
why this is not allowed.. for example, does the GCM server monitor and keep
track of server keys and the source IP they are from?
Thanks so much - been searching for days and cannot get a real hard answer
I feel I can trust. My whole development project design hinges on the truth in
this matter - ha ha !
Receiving Messages from Multiple Senders
"GCM allows multiple parties to send messages to the same application. For example,
suppose your application is an articles aggregator with multiple contributors, and
you want each of them to be able to send a message when they publish a new article.
This message might contain a URL so that the application can download the article.
Instead of having to centralize all sending activity in one location, GCM gives you
the ability to let each of these contributors send its own messages.
To make this possible, all you need to do is have each sender generate its own project
number. Then include those IDs in the sender field, separated by commas, when requesting
a registration. Finally, share the registration token with your partners, and they'll
be able to send messages to your application using their own authentication keys.
Note that there is limit of 100 multiple senders."
or worded another way in some other doc ....
Receiving Messages from Multi-senders
"GCM allows multiple parties to send messages to the same client app. For example,
suppose the client app is an articles aggregator with multiple contributors, and
each of them should be able to send a message when they publish a new article. This
message might contain a URL so that the client app can download the article. Instead
of having to centralize all sending activity in one location, GCM gives you the ability
to let each of these contributors send its own messages.
To make this possible, make sure each sender generates its own sender ID. See the
client documentation for your platform for information on on how to obtain the GCM
sender ID. When requesting registration, the client app fetches the token multiple
times, each time with a different sender ID in audience field.
Finally, share the registration token with the corresponding app servers (to
complete the GCM registration client/server handshake), and they'll be able to
send messages to the client app using their own authentication keys.
Note that there is limit of 100 multiple senders."
and even in some register code I saw.....
chrome.runtime.onStartup.addListener(function() {
chrome.storage.local.get("registered", function(result) {
// If already registered, bail out.
if (result["registered"])
return;
// Up to 100 senders are allowed.
var senderIds = ["Your-Sender-ID"];
chrome.gcm.register(senderIds, registerCallback);
});
});
For Google cloud messaging, is there a use for storing the token? Or can we just work with the registration id? Trying to setup push notifications and was wondering why they use both tokens and registration ids.
Use the token on your server, to specify the device you want to send a message to. You, as a developer, have no significant use for the registrationID, in terms of actually sending the message.
From my understanding, token is used to authorize your application' access to Google Service while registration id is the unique identifier of an app on a specific device. GCM uses Registration ID to identify the device and app to send push notification to. So to answer your question, you need both of them.
This is an authentication flow, which logs in the user with only the phone number provided (Whatsapp style). The Steps are:
User enters phone number and sent to server.
Server generated 4 digit random key, and save the pair (phone,key) in DB.
Server asks 3rd party SMS service to send key to phone.
SMS service sends message.
User enters the key from sms, and together with phone, sent to server.
Server checks the pair against the DB.
If pair exists, server sends back a token for further calls.
What I am trying to understand is where services like Twilio and Nexmo fit in (or replace parts of the flow).
From what I understand, looking at Nexmo for example,
I can replace steps 2 and 3 with an API call to:
https://api.nexmo.com/verify/
and save the request_id from the response in the DB as pair (phone,request_id).
And now, when the user enters a 4 digit code and sends it back,
I need to call:
https://api.nexmo.com/verify/check/json
providing it with request_id and code.
But where do I get the request_id?
Do the server needs to send it back to the client, the moment it gets it from Nexmo?
I can't see the benefits of using Nexmo here, what will it save me?
Answer to your first question: the request_id is part of the response to the first verify API call. See: https://docs.nexmo.com/index.php/verify/verify
As to what are the benefits of Nexmo here, I believe you have two options:
Generate your own code, use Nexmo to text it to your user, have the user submit the code back to your application, verify code against your own database.
Use Nexmo verify service to generate and send the code to the user, store the returned request_id in your db, have user submit code to your application, call Nexmo verify API to validate code.
In some ways the first option is easier as it is less API calls. However the benefit of the second option, using Nexmo Verify, is that they provide a whole lot more capabilities into the service to fall back to a voice call if SMS isn't working, filter out virtual phone numbers to prevent spam, you don't have to pay for failed SMS attempts, reporting/analytics, etc. etc.
Hopefully that helps a little.