When using the PubNub Presence feature, is it possible to provide a HTTP callback that PubNub calls when a user joins or leaves a channel? In my case I want to call a Parse.com cloud function.
To clarify: I don't want to call the function from a client, but have the PubNub.com servers take care of it.
Calling a web service on PubNub Presence events
PubNub offers Presence "HTTP Callback" generated from PubNub.com servers. You must ask your Account Manager to enable for you; send an email to support#pubnub.com to enable. Ask for "Presence Callback Active" and "Presence Callback Inactive" settings. You'll want to setup a dev/prod key pair to point the WebHook URLs at different environments.
The HTTP callback URL that is triggered when a channel becomes active.
Webhooks are now supported for all presence events: join, leave, timeout and state-change, as well as the channel active and inactive events.
For a full explanation please read this StackOverflow about PubNub Presence Webhooks and how to get them configured for you keys.
Related
Scenario
When business transactions are performed, we're supposed to make that data available to end clients.
Current Design
Our web app publishes transaction messages are added to a topic on the Azure Service Bus.
We expose APIs to clients through which they can consume the data from those transactions.
Upon calling these APIs, we read the messages from the Subscription and return it to the client.
Problem
We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.
So we only want to do a "Peek" instead of "Receive".
So the client calls the first API, to get the data, where we do a Peek.
And once the client has received the packets, the client would call a second API, to acknowledge.
At this point, we want to remove the message from the Subscription, making it Complete.
The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.
Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.
Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service.
However this will be a problem when the App Service scales out.
Is there a different way to achieve what we're trying to do here ?
There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.
The first client should receive the message and instead of completing it, it should defer it and return it.
The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.
Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).
There are APIs to
Peek-Lock
Renew Lock
Unlock
Delete (Complete)
You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.
PS: Cross posting the answer for the same query on the MSDN forum
The azure event grid allows an https endpoint (my web hook event handler) to be registered with a subscriber for a topic. So when an event is received by the topic that matches the subscription filter criteria, the event is pushed by the event grid to my https endpoint.
I have a use case where the my https endpoint requires a client certificate to be supplied with this http push mechanism by event grid.
Does event grid allow a way to attach/configure a client certificate, related to the my web hook https endpoint? If so, how do I configure this?
If the client certificate functionality (for push) is currently not available in event grid, what are the other easier security mechanisms that I can employ to keep out unwanted and malicious events push by non-event grid publishers? (Other than firewall rules, white listing of IPs etc.)
Thanks.
For your scenario can be used an EventGridTrigger Function as a subscriber-integrator to your client endpoint. This function will handle forwarding an event message based on your needs.
Update:
Other option using a declarative integration for delivery an event grid to the https endpoint with a client certificate authorization is subscribing by Logic Apps and then forwarding to the custom endpoint. The following screen snippet shows this case:
Note, that the Azure Event Grid supports customizing a Webhook subscriber endpoint only at the url address (included a query string). That's documented in the https://learn.microsoft.com/en-us/azure/event-grid/security-authentication as it has been commented by #KenWMSFT.
Both of Roman's answers should work quite well. Depending on your particular constraints and throughput, a third option would be to use Hybrid Connections as an intermediary.
This would involve adding a bit of code at your event handling endpoint to open a WebSocket connection to Hybrid Connections, and then routing your events form Event Grid to Hybrid Connections.
This should allow you to fully circumvent your client certificate issue and would allow for high throughput. The downside is adding some client-side code to open the WebSocket. The best solution for you is highly dependant on your requirements.
Here is a sample on using Hybrid Connections to route events if you choose to go that route.
I am creating a bot using Microsoft Bot Framework (BotBuilder) and want it to message the user when an appointment is about to begin.
I currently use Microsoft Graph api to access the user's Office 365 calendar and store the appointments. A background thread then keeps track of time and then messages the user when an appointment is about to start.
The current idea is to use Graph webhooks to notify my bot about new appointments.
My question is, would it be smarter to use an Azure service (such as Scheduler) to keep track of the appointments, and send rest messages to my bot, which will then send a message to the user?
My worry is, that as the amount of users rise, the amount of appointments and time checks will become too large, and that maybe Azure services would be able to handle it better.
This is a perfect fit for Azure Functions with a HTTP Trigger.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook
This article explains how to configure and work with HTTP triggers and bindings in Azure Functions. With these, you can use Azure Functions to build serverless APIs and respond to webhooks.
Azure Functions provides the following bindings:
An HTTP trigger lets you invoke a function with an HTTP request. This can be customized to respond to webhooks.
An HTTP output binding allows you to respond to the request.
I'm trying to piece together the general workflow of giving a user push notifications via the service worker.
I have followed this Google Developers service worker push notifications tutorial and am currently thinking about how I can implement this sort of thing in a small user based web app for experimentation.
In my mind, the general workflow of an web app supporting push notifications is as follows:
Client visits app
Service worker yields a push notification endpoint
Client sends the endpoint to the server
Server associates the endpoint with the current user that the endpoint was generated for
Every time something that your app would say is notification worthy happens, the server grabs the push notification endpoint(s) associated with the user, and hits it to send a push notification to any user devices (possibly with a data payload in Chrome 50+, etc)
Basically I just want to confirm that my general implementation thoughts with this technology are accurate, else get feedback if I am missing something.
You are pretty much bang on, there are some specifics that aren't quite right (but this is largely phrasing and may be done to personally taste).
Client visits app
Register a Service Worker that you want to use for push messaging
Use the service worker registration to subscribe the user to push messaging, at which point the user agent will configure an endpoint + additional values for encrypting payloads (If the the user agent supports it).
Client sends the endpoint to the server
Server store the the endpoint and data for later use (The server can associate the endpoint with the current user if the server if the web app has user accounts).
When ever the server wishes to send a notification to a user(s), it grabs the appropriate endpoints and calls them that will wake up the service worker which can then display a notification.
Payload support in coming in Chrome 50+ and at the time of writing payload is support in Firefox, but there are 3 different versions of encryption used for the payloads in 3 different versions of Firefox, so I'd wait for the payload support story to be ironed out a little before using it / relying on it.
For a startup considering making public notifications intended for website users available via a Pusher channel, how do you prevent people from subscribing to that channel for a long period of time (camping essentially)? I know you can disconnect users after a period of inactivity if they are connected from a web client (by checking for activity on the client and sending a disconnect after a period of inactivity), but what if users decide to connect via a command-line app or something similar?
Pusher provides private channels where the subscription to those channels need to be signed using your application secret in order for the subscription to be allowed.
Given the command-line app example you've provided the author of that application would not know the application secret and would therefore not be able to subscribe to the private channel.