The exact POST I made to create exactly 1 subscription on 1 resource:
POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json
{
"changeType": "created",
"notificationUrl": "https://myurl.com/endpoint",
"resource": "/me/mailfolders('inbox')/messages",
"expirationDateTime": "{{addMinutes(now; 4225)}}",
"clientState": "{{uuid}}"
}
Microsoft Graph notifications for changes in resource data Doc
What's weird is that sometimes it sends the same data to my URL 2 times, sometimes just 1, sometimes 3. I know they're duplicated because they're completely the same (I used a difftool).
I've read this, that, and this but I just couldn't understand why its possible to send out more than 1 webhook for a "created" notification. I'm responding with a 202 as soon as I get the POST and these duplicated POSTS are not even 1 second apart so not sure if I could store the "#odata.etag" and check if its already in a database as I use integromat to receive these change notifications.
So what gives? How can I make it so that I only receive 1 notification? Does it have something to do with how the mailbox is setup? Is storing the #odata.etag really the proper way to handle this? Really absurd if that's the case.
This might be due to the known issues in Change notifications:
For information:https://learn.microsoft.com/en-us/graph/known-issues#change-notifications
Related
When someone installs my application to their google workspace, does google send any kind of notification to my infrastructure - say via webhook?
Or am I responsible for the onboarding/first-run experience on my own, either via polling or upon the first time a user visits my application?
To my knowledge, Google doesn't notify you directly anywhere. To do this you have to use the licenseNotification.list API. With this you can get a list of installs/uninstalls of your app along with the user emails. A sample response would look like this:
{
"kind": "appsmarket#licenseNotification",
"id": <some-notification-id>,
"applicationId": <your-app-id>,
"customerId": "email#example.com",
"timestamp": <unix-timestamp>,
"provisions": [
{
"kind": "appsmarket#provisionNotification",
"editionId": "default_edition",
"seatCount": "1"
}
]
}
As you can see, it contains the email of the user and whether or not it was provisioned. It also returns a nextPageToken with the last notification id, so you can store it and send it in your next request as startToken and get results after the last notification you got. With this in mind, you could build some kind of Pub/Sub service to poll the API periodically and notify your app when you get new provisioned users.
Reference:
licenseNotification.list
My app is implemented in React Native and is using Firebase for notifications. We have webhooks on the web app that are triggered on certain events. Those webhooks then send a request to the respective Firebase Cloud Function. With information from the request's header they get the topic they must send the notification to; from the request's body it gathers the information to be sent as data to the device. They are sent as data notifications only, the handler (using the React Native FCM API) then shows a local notification already translated with i18n using the react-native-push-notifications package. Everything works fine until I hit the weird situation described below.
Everything was doing alright both on Android and iOS until I launched the app on Test Flight for internal testing and then it stopped working after some time on iOS. Eventually, I noticed that when more than one iPhone subscribed to the same topic it eventually lead to inconsistencies in the delivery of the data notifications. The first iPhone to subscribe to the topic usually worked, the others didn't, the first one most of the time eventually stopped working as well or sometimes it just kept working while the others still didn't. I used the Firebase Console to send some test notification to the subscribed devices and it they actually received it. I then changed my Cloud Functions' code to avoid sending any data and just send some example body and title and it turns out the problem was here. As soon as I send something through the data field in the admin.messaging.Message object to be sent as argument to the admin.messaging().send method, they aren't received by the iPhone devices subscribed to the topic (or it's received by one or two max, the first ones to currently subscribe to the topic. But they usually stop receiving them after a while as well).
This is really really weird and being so inconsistent makes it practically impossible to debug with my current knowledge. Some things to keep in mind:
All Android devices still receive the notifications without a problem
I've watched the iPhone's console through Xcode to see if there was some error when processing the notification, in case they were actually getting the notification but they it failed before it was shown to the user. But nothing is logged by the SpringBoard process, making me conclude the notifications aren't actually getting to the device
I've manually sent notifications with cURL to APNs (with this guide). They were received fine
All notifications without data, regardless of the iOS specific apn headers, payload, etc, are received
What can be the cause of the problem? Or there's something in my code causing this strange behavior (which I doubt, since it works fine on Android and works fine in iOS as well on specific scenarios), there's some type of bug on Firebase's side causing some notifications to not be sent or, finally, there's some error on Apple's APNs side causing this. Highly doubt the last one, if the fault lays on any exterior factor it probably should be on Firebase's handling of topics.
Really would appreciate some help. Thanks in advance. Sorry If I didn't gave enough information, I actually never had the need to do a question on Stack Overflow. I'll leave below an example of a cloud function as well.
exports.orderPending = functions
.region("europe-west2")
.https.onRequest((req, res) => {
if (req.method == "POST") {
res.status("200").send("Webhook successful");
const topic = req.headers["code"];
const message = {
data: {
id: JSON.stringify(req.body.order.id),
event: "orderPending",
order: JSON.stringify(req.body.order),
},
topic,
android: {
priority: "high",
},
apns: {
payload: {
aps: {
contentAvailable: true,
},
},
headers: {
"apns-push-type": "background",
"apns-priority": "5",
"apns-topic": "APP BUNDLE ID HERE",
},
},
};
functions.logger.log(req.body.order.id);
functions.logger.log(topic);
admin.messaging().send(message)
.then((response) => {
console.log("Successfully sent message: ", response);
})
.catch((error) => {
console.log("Error sending message: ", error);
});
}
});
Turns out the data payload was exceeding the 4KB APNs limit but since when you send by topic it doesn't show any errors at all I had no way of knowing. So yeah, add this to your checklist
I have a calendar tool that integrates with Outlook Calendar. To respond to changes on the Outlook side, I subscribe to push notifications. If I miss the first notification of a change, Outlook sends others with ChangeType: 'Missed' and I synchronize with the user's calendar to retrieve the details of the change. However, deleted events do not seem to be included in the sync response.
The documentation suggests that it is possible to get deleted events:
Synchronize and get new, updated, or deleted events in a specified time range from the user's primary calendar (../me/calendarview) or from a different calendar.
There is even a section about deleted events and synchronization.
Deleted events will contain a reason property with the value of "deleted" to indicate a deleted entity. If the event is a recurring master event, you should delete all of the occurrences and exceptions.
'Created' and 'Updated' ChangeTypes work fine.
Am I subscribing incorrectly? Or is this not a feature of the Outlook Calendar API?
Here is the body of my subscription request:
{
'#odata.type': '#Microsoft.OutlookServices.PushSubscription',
'Resource': "https://outlook.office.com/api/v2.0/me/calendars/#{calendar_id}/events",
'NotificationURL': MY_URL,
'ChangeType': 'Created, Updated, Deleted',
'ClientState': 'foo',
'SubscriptionExpirationDateTime': TTL.minutes.from_now.iso8601
}
When a user logs out, I do:
FIRInstanceID.instanceID().delete(handler: { (error) in })
Which should (?) invalidate the token and unsubscribe from all topics.
It works, but logging in with the same device and calling FIRInstanceID.instanceID().token() (from notification when it's ready), I get the same token (not really a problem, but unexpected). However; subscribing to topics (upon login for instance) seems to be cached in the device from the previous login, so it doesn't make a network call, meaning the token will not be associated with any topics on the FCM side. Assume it's the same user doing a relog; the topics he/she wants to subscribe to are the same as before delete().
I can verify this by querying https://iid.googleapis.com/iid/info/<token> with the token: Even after calling subscribeToTopic in my app, the list of topics remains empty. Normally this call results in the -5 error (described here https://github.com/firebase/quickstart-ios/issues/146) when subscribing to multiple topics, but nothing happens, indicating to me that the application thinks it's already subscribed to the topics and hence does nothing.
So - how can I unsubscribe from all topics upon logout, and successfully resubscribe when logging in? Looping the topics and doing unsubscribeFromTopic seems a little hacky to me.
Instead you can disconnect the user from getting push notifications by doing FiRMessaging.messaging.disconnect()
And connect the user when he logs back in
Using a production key on Mandrill I am attempting to send an email. Previously this has worked without issue. However now, despite receiving a successful response from the API, visible in the api log, no email is being sent, and nothing is present in the outbound activity log.
If I check the api log for the message which appeared to fail it displays:
[
{
"email": [email_address],
"status": "sent",
"_id": [id],
"reject_reason": null
}
]
Replacing the id in the content view of a sent email, with the id from a failed one displays a correctly formatted email:
e.g. https://mandrillapp.com/activity/content?id=20151214_[put_the_id_here]
Is this a bug? What is causing it? Where can I see more information about what happened? How can I monitor if this happens again in the future? How can I prevent it from happening in the future?
I have been in contact with Mandrill support regarding the issue, which they described as 'very strange indeed'. Deleting the API key and generating a new one fixed the issue, but there is no explanation as to why this is they case, how to detect the problem, or how to stop it from happening again in the future.
The messages in question were never actually sent by Mandrill, and displayed no SMTP events, despite reporting as sent by their API
Something else to check is to make sure you're using a working API key instead of a test one. As the name suggests, test keys are designed to work just like a regular key, so the feedback to your program will be identical, but the messages won't actually be sent.
You can see if this is the problem by going to the Mandrill settings and looking at the list of API keys. Test keys have a very clear This is a test key message listed.
This probably won't be an issue if you generated the key yourself, but if you inherited this project it's worth taking a look.
I have faced a similar issue like this last week. The "sent" status only indicates that Mandrill sent it. But reception of the email message is confirmed only if there is a SMTP event corresponding to it with code starting with 2, (example 250 etc), in the info api response, like the following:
"smtp_events": [
{
"ts": 1442448422,
"type": "sent",
"diag": "250 SmtpThread-4622542-14682902148#ps-they-19.uk.miplecast.lan Received OK",
"source_ip": "505.207.171.171",
"destination_ip": "705.139.255.221",
"size": 29501
}
check this link for more info.
https://mandrill.zendesk.com/hc/en-us/articles/205582697-How-to-Confirm-If-an-Email-Was-Actually-Delivered
the issue could be on the recipient server as well, due which delivery could be delayed. In our experience last week, the message was delivered 4 hours after being Sent. we were not able to establish the reason yet why, this delay happened.
HTH,