I have a WCF Service and and an Website(say www.GoogleNotificationCallback.com) to receive Google Push notification from Google calenders.
Whenever some event is updated/Deleted/Added on Google calendar, it sends back an notification to my Endpoint(www.GoogleNotificationCallback.com)
To manage the load for incoming requests from google calender for push notification, I have load balancing servers on which I have my website(www.GoogleNotificationCallback.com) and WCF service hosted.
Every thing is working fine, but the issue is, if I create/Update/Delete/Move any Event on Google Calendar it sends back multiple hits to the endpoint(www.GoogleNotificationCallback.com).
I checked for ChannelId, MessageId and CalendarId from the current Context.
{var context = HttpContext.Current;
string reqheaders = "reached";
var actualRequest = context.Request;
var reqKeys = context.Request.Headers.AllKeys;}
But for each current context.Request I am getting same CalenderId but different ChannelId and MessageId.
I am not able to understand why Google is creating multiple channels for an single change ? OR why it is giving multiple push notifications to my end point (www.GoogleNotificationCallback.com)?
Is there any settings that i am missing or via coding i am doing any mistake.
can any one please guide me for the same?
Related
I have successfully connected to Microsoft Graph using OAuth. I can receive and send emails from my Office365 account.
But I am completely stuck on how to receive emails automatically, similar to the IMAP IDLE routine.
I am referencing
using Microsoft.Graph;
using Microsoft.Toolkit.Services.MicrosoftGraph;
I have tried Subscription but have no clue what to do next, or even if this is correct.
Subscription sub = new Subscription {
ChangeType = "created",
NotificationUrl = "urn:ietf:wg:oauth:2.0:oob",
Resource = "/users/me/messages",
ExpirationDateTime = DateTimeOffset.Now.AddMinutes(20),
ClientState = "????" // if applicable, what is this
};
To make a subscription you need to expose a notification URL with https (see graph documentation).
POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json
{
"changeType": "created,updated",
"notificationUrl": > "https://webhook.azurewebsites.net/notificationClient",
"resource": "/me/mailfolders('inbox')/messages",
"expirationDateTime": "2016-03-20T11:00:00.0000000Z",
"clientState": "SecretClientState"
}
If you want examples the graph documentation references a Node.js and asp.net example. Both use ngrok to expose an https URL (just for testing purposes though). The program tunnels HTTP requests through to your localhost (like a reverse proxy). If you have that setup, you have to validate your request. When you send your subscription request the first post message your notification URL will receive is a message with a validation token (see doc). You have to send this validation token back. Now you should receive notifications on your specified notification URL.
You can read about the Subscription resource type and its properties in the graph documentation.
For example, the client state is described as:
Specifies the value of the clientState property sent by the service in each notification. The maximum length is 255 characters. The client can check that the notification came from the service by comparing the value of the clientState property sent with the subscription with the value of the clientState property received with each notification.
Subscriptions are not in possible at this moment using Microsoft Graph for UWP, for notifications the Outlook 365 API should be used. The Microsoft graph api can be used for Auth and other tasks though.
Can Microsoft consider including streaming notifications in Microsoft Graph?
I've built a small basic web bot app using bot framework and want to deploy it on Azure. I've followed all the steps and it's working fine under "Test in Web Chat" of Azure Portal too, but however as I open my bot's endpoint
https://optlbot.azurewebsites.net/api/messages
I get an error saying
The requested resource does not support http method 'GET'
Can somebody please help me, I can't debug my application at all. I've also tested on emulator and there too it's working fine.
Yes, the URL https://optlbot.azurewebsites.net/api/messages works only for POST request and not a GET request, because you post a message from user to bot and not a get, you can see that in the MessagesController code.
Being said that, if you want to test your bot locally, you have to use the emulator. You can have a look at Bot emulator for the same.
Now if you want to publish the bot to the world so that others can see it and use it, so that's where the channel comes in. Consider channel as a medium by which you enable your bot for others to use with a much better user experience.
There are multiple channels available for the bot to be published in, and yes you can publish the same bot in all the channels.webchat is just one channel and the one which is enabled by default and the way to see it is :
Open your bot in the Azure Portal and click Channels blade.
Click Edit for the Web Chat channel
Under Secret keys, click Show for the first key
Copy the Secret key and the Embed code.
Click Done
So the embed code is actually an iframe which you can place in your website or share with others who want to use your bot. Or you can use the src of the iFrame too to reach the bot directly.
Again this is just one channel. You can take a look at the Configure channels documentation for steps to enable the bot in more channels like Skype, Microsoft Teams, Email, Facebook, Slack, Telegram, etc.
If you check the code of your MessagesController, you would find the following action defined in your controller, it only accept POST request and read the value of activity from the request body, it does not support http method 'GET'.
/// <summary>
/// POST: api/Messages
/// Receive a message from a user and reply to it
/// </summary>
public async Task<HttpResponseMessage> Post([FromBody]Activity activity)
{
if (activity.Type == ActivityTypes.Message)
{
await Conversation.SendAsync(activity, () => new Dialogs.RootDialog());
}
else
{
HandleSystemMessage(activity);
}
var response = Request.CreateResponse(HttpStatusCode.OK);
return response;
}
I am getting the EWS URL as below:
var response = myAutodiscoverService.GetUserSettings(
"userA#domain.com",
UserSettingName.ExternalEwsUrl,
UserSettingName.InternalEwsUrl,
UserSettingName.EwsSupportedSchemas);
string settingValue;
if (response.TryGetSettingValue(UserSettingName.ExternalEwsUrl, out settingValue)
|| response.TryGetSettingValue(UserSettingName.InternalEwsUrl, out settingValue))
{
// If ExternalEwsUrl is not returned in the response,
// we consider InternalEwsUrl for auto-discover
string ewsurl = settingValue;
}
Now, I am caching this ewsurl I get with this request as recommended since auto-discovery is really slow. What happens when this ewsurl expires (because let's say user's mailbox was moved to a different endpoint). What error should I expect in order to implement a failure mechanism to get the new updated ews url?
Edit: I am using the ews url to subscribe for new mail events on EWS using ExchangeService.SubscribeToPushNotifications So I have another question, suppose if the ews url was changed after user subscribed for notifications, will I get a notification for that user for a new mail event on the callback url of my application?
I seem to recall the ROT from MSFT was you should re-autodiscover every 24 hours, but I've not seen anything recently. As to the Push notifications: since there is a "heartbeat" facility in Push notifications, if you miss two heartbeats in a row, it's safe to say you should tear down the subscription and re-subscribe, which to be safe, implies re-autodiscovery. Of course with O365, since the EWS URL seems (for now) to always be the same, re-autodiscovery is less of a concern.
Im using Facebook C# SDK to post and fetch data. These simple tasks took forever to get running properly. Now I need to notify my webpage(ASP.NET C#) about changes on the specific facebook page so the webpage knows then it should fetch new data.
I have looked at this page : https://developers.facebook.com/docs/graph-api/real-time-updates/v2.2
But as usally with facebook documentations it misses to explain in detail how it works and how to get it working. Where exacly do I create the subscriptions? It says /{app-id}/subscriptions but I have tried this url with my app-id but no page is found?
I have tried to find examples on how to set this up but to no sucess.
Could someone please explain how this works? What do I need to do exacly to get this running?
Facebook subscription works by pinging a URL you own every time data has changed. You need to add a URL you own as a callback URL for Facebook subscriptions to work with
POST /v2.2/{app-id}/subscriptions HTTP/1.1
Host: graph.facebook.com
object=page
callback_url=http%3A%2F%2Fexample.com%2Fcallback%2F
fields=feed
verify_token=thisisaverifystring
In the above API request a POST request is made to add http://example.com/callback/ as the callback URL subscribing to the feed edges of the page object (a page object that the session user owns)
In your callback URL you must have it handle two actions
the initial callback (Handling Verification Requests via the verify token)
saving updated subscriptions (Receiving the Real Time Updates)
Here is an example of what it looks like in PHP
<?php
if ($_REQUEST['hub_verify_token'] === 'thisisaverifystring') {
echo $_REQUEST['hub_challenge'];
}
$file = 'sample.txt';
$inputJSON = json_decode(file_get_contents('php://input'));
file_put_contents($file, file_get_contents('php://input') );
?>
A stored notification channel URI may go stale while my app is inactive -- i.e., stopped, tombstoned or dormant. What is the best practice for updating the channel URI with my web service after a period of inactivity?
Various articles on the web mention "retrieving" the URI in order to send it to the web service. But as far as I can tell, the only way for my app to learn the channel URI is via the ChannelUriUpdated event on HttpNotificationChannel, and raising that event is not under my control. MPNS may have changed the URI while my app was inactive. If the app could not respond to ChannelUriUpdated, the URI would then be stale in both my app and my web service.
Perhaps a channel returned by HttpNotificationChannel.Find is guaranteed to always have an up-to-date channel URI?
General best practice is to request the current channel Uri whenever the app is started. Within the app you should keep track of the last value returned (across application invocations) and if it's changed to upload to your web service.
Please follow this Updated document here. what it does is, it executes a script on insert of the channel uri, it checks if the channel URI exits, if it exists it does not insert the record, else it inserts the record. so, once the channel uri for a device expires, a new channel uri is given to the device in that case, the comparision mismatches and the new channel uri is inserted. by doing that the device is always sent the notification.
Note:- to leverage that functionality, you have to send for insert every time your app starts. hope this helps.