When you add a stream activity entry, you are binding that stream to a place. IMO, it makes more sense to create a single webhook for the place and ignore all the extra webhook entries.
You can obtain a token and create the webhook during the Tile configuration page if you’d like … this way you have a token that is scoped to that place; however, if you’d like to use a single token that you capture during add-on configuration … that would work as well.
In the end, you definitely don’t want to create a webhook per individual piece of content.
Note, depending on what you need to get from the system, you may consider using the Data Export Service to scan for events periodically and take action …
Both are acceptable patterns, it just depends on how you want to structure it.
Let me know if that doesn’t help.
My concern with this approach is security when a client configures their instance to post updates to the top-level "Jive" place rather than a "recognition" place.
Would this would mean we receive any event, regardless as to its content?
I guess a follow up question would be is it possible to subscribe a Webhook to a subset of Activity events based on ActivityObject objectType?
There isn’t a way to subscribe just to activity, but you can subscribe to the entire place.
For example, Place ABC and Place DEF in Jive. With Place ABC you add the Activity Tile from TemboSocial for Activity in Recognition Place 123. You do the same for Place DEF, except you use Place 456. During the configuration of each Activity Tile, you have an Oauth Grant button that creates a token from the person configuring the Tile for that specific Place. When you save the tile you have the following details:
-Tiles URL, accessToken w/refresh for the tile and config parent (place)
-You will also have stored the Oauth access/refresh tokens for the general purpose API.
At this point, you call and register a WebHook for Place ABC/DEF respectively using the appropriate access/token you captured in the configuration process.
This should create the place level activity from the Jive place. If you’d like to have all the web hooks come back to the same URL, that is fine, or you can give each webhook you create a predictable URL, such as /webhooks/inbound/jive/content/place/abc)
Conversely, if you’d like to use 1 set of credentials to create/manage these web hooks … you can also do that…but the pattern remains the same.
Does that help at all?
It does - Thanks Ryan!
Since there is no filter I'll have to talk to the team here about the security/confidentiality concerns about potentially receiving all content from a client's Jive instance (e.g. bank/investment institution) if they choose to post global Activities.
We'd never actually do anything with non-recognition activity but we need to consider it even being broadcast to us and any logging implications.
Fair point. Also, keep in mind the details of the information you get from jive. It is similar to this:
So the threat of leakage is quite low. This is why you require credentials to get the details. =)
Hi Ryan, a follow up question that's kind of unrelated but was sparked by your suggestion to use the Tile oauth token.
I was planning on using Core V3 API - Run-As Feature & Signed Add-Ons in order to do server-to-server communication easily.
Is this a bad idea? Will clients (such as, say, Jive) sign our packages and allow this?
Unless you have a need to use Run-As, I would avoid it. But that is my personal preference.
That being said, wrt to Signing an add-on, this is something that would need to be done on a per Jive instance basis, and it would need to be done by the system administrator of that instance. The only real draw back is that you won’t be able to distribute a single add-on zip to all customers. All customers would have their own signed version of your add-on. This could be good, bad or non-impactful … all depends on how you guys build your add-on zips.
Does that help?
Thanks Ryan, we just want to make things as easy/minimize scary screen as much as possible for people using the tiles.
The whole OAuth/grant permission thing for each tile install might turn people off if we use individual tile authorization. The run-as actually seems much cleaner from both a frontend user experience as well as the backend code organization (single token per jive instance, rather than juggling lots of tokens per tile install).
Agreed, it’s a personal decision…but collecting a single auth token at Add-On install doesn’t mean you have to use Run-As with a signed add-on. The same way you have a configuration screen for a tile, you can have a configure screen for your add-on which uses the same tech. You simply need to capture it and store it centrally. The person installing the Add-On should be a system-level admin, which should allow you to use run-as the same way without having to sign the add-on (I think) =)