-
-
Re: Jive Application Gateway Questions
The app gateway serves a couple of functions. First, for applications that are integrating into Jive that may be deployed across multiple instances, it simplifies credential management. Specifically, one key/secret is provided to the app and will work across all jive instance. So, when an app does an osapi call and requests it to be signed, it will pass through the gateway. Also, as you point out, this also allows activities to be posted back to Jive asynchronously. In 6.0, we have the V3 API, this has much more coverage and you can now do things like post an activity via REST directly. However, the catch is that you currently need to use basic auth (as compared to OAuth that the gateway uses).
There are no plans to make the gateway on-prem.
The requirements for communication are as simply that the jive instance has visibility to the gateway IP address. Technically, the app's home server posts an activity, this gets places in a queue. Then the jive instance periodically polls the gateway. This way, there are no ports on the firewall that need to be opened.
-
Re: Jive Application Gateway Questions
Can you then explain what information is actually sent to the App Gateway?
And just to qualify what you are saying, in order for us to use the outlook plugin utilizing Oauth, we must connect to the hosted application gateway?
-
Re: Jive Application Gateway Questions
The OAuth used in the outlook plugin is different than the gateway. The two are independent.
-
Re: Jive Application Gateway Questions
So when you say (three times for some reason
) that the OAuth in the Outlook plugin is different than the OAuth in the app gw, are you saying that the our on-premise JIve app would need to communicate with the Jive Data Ctr app gw using Jive's OAuth even if it didn't want to push activity updates into our on-premise JIve instance which itself only has to poll the app gw for those updates while our on-premise Jive instance and outlook plugin need to be able to access our on-premise OAuth infrastructure once it's deployed if we want to use OAuth instead of basic or session based authentication ?You said the 2 OAuths are different so which one would the Jive Anywhere plugin need to use ? My bet is it's our on-premise OAuth that the Outlook plugin would also use.
-
-
Re: Jive Application Gateway Questions
The OAuth used in the outlook plugin is different than the gateway. The two are independent.
-
Re: Jive Application Gateway Questions
My understanding of OAuth is for external application to validate your authentication and pass a secret key along that will be accepted by the other sites.
This should not be needed for the Outlook plugin. If we are using SAML as the SSO authentication transport, how does OAuth play a role in Outllook SSO, if at all?
-
Re: Jive Application Gateway Questions
Ooops, I was momentarily confused and was thinking of Jive Anywhere.
-
-
-
-
-
Re: Jive Application Gateway Questions
The Application Gateway is a bit confusing to me as well. I have been attempting to create a Jive application using v3 of the core api and rest api, and I'd like to post Activities to users on behalf of the app through the rest API.
What isn't clear in the documentation is if you are sending an Activity to a list of users, do you just need the username/pass for only one of those users to pass for basic auth, or do you need an admin's credentials? In my testing, when using my credentials to post an Activity to 3 different people (myself being one of them), all 3 people get an email from Jive saying they have a new Activity, but I'm the only one who actually sees that Activity show up inside Jive (we are using the cloud offering right now). Furthermore, the activity says "via Inbound Activity Service" instead of being from my application.
When I post an Activity to the same 3 people via the javascript core api from within the app, all 3 people see the Activity inside Jive and they all show as "via <app name>".
I've seen the Application Gateway in several different documents, but nothing in the official v3 API documentation. Would really appreciate if someone could give me some pointers. Thanks!
-
Re: Jive Application Gateway Questions
There are several use cases that we are talking about here, all of which deal with posting an activity to the stream.
Use case #1: An APP posts an activity to the stream on behalf of a user
In this use case, the activity is posted through the gateway. There is a link to the application in the incoming activity and the user, on behalf of which the activity is being posted, MUST have the app installed.
Use case #2: Posting an activity via the JavaScript API
In this use case, the osapi is called directly from the app. For all intent and purposes, it looks like any activity that comes in via an app. Here's one from the code runner.
In both of the above use cases, notice there is the app icon in overlaid on top of the the user's avatar. This is an indication that this was posted via an app. Also, there's the "via <app name>" in the footer. Also, NO USER CREDENTIALS were supplied. Posting via the gateway leverages the OAuth key/secret that was provided to the app. Posting via the osapi means the user is in the application itself in Jive, so you know who it is.
Use case #3: Use the V3 REST API
In the V3 API, you can now post activities using REST. This is done with basic auth and requires the user credentials. It will look like any other activity entry that is the result of behavior in the system.
I hope this clarifies some of the confusion. I'll try to find time to update the docs accordingly and appreciate your indulgence.
-
Jan 2, 2013 1:51 PM
