Hi Gwowen Fu! I think you'll get better visibility on this thread if you move it to the Jive Developers space. To do so, click on 'Move' in the actions panel to the right of the conversation, and then start to type 'Developer' - you'll see the space and get the right eyeballs on your question. Thanks!
Thanks, question moved to Developer space.
I have the same question (in a different thread).
When I use Firefox RESTClient plugin to create token, it requires authorization endpoint, token endpoint, and redirection endpoint.
When I run the curl command, tokens are generated:
curl -u 6ceeivjb6e83xv35ngsea50tbp6xr5oh.i:niwg4ot33eutwsxxlf5vivhclr6s27am.s -email@example.com&password=xxxxxxxxxx' https://devrygroup.jiveon.com/oauth2/token
Hope that helps.
When should I update "service_url"?
My app is Jive hosted so the "clientUrl" in jiveclientconfiguration.json is not relevant, right?
localhost:blank gwowen$ cat ./extension_src/meta.json
"name": "Add-on containing apps(s)",
"description": "Apps: [Simple App Skeleton]",
localhost:blank gwowen$ cat jiveclientconfiguration.json
"development" : true,
"logLevel" : "DEBUG",
"suppressAddonRegistration" : true
When your add-on is registered, your service receives a JSON payload with Jive instance details and the clientId/clientSecret issued by Jive. If you want to get these manually, simply visit the Add-On page and click on the dropdown to the right of your add-on, and select View Client ID / Secret.
If you are hosting your app in Jive, then you can set the clientUrl to "http:" and this will disable the registration response to a remote service on install, and you can manually grab the ID/secret from the menu (see above).
redirect_url should be set to whatever URL you want the remote service's OAuth token granting page to redirect to on your end ... such that you can receive the request and capture the tokens. Normally, your service will read the parameters and persist them into a DB of sorts to use whenever said user is trying to invoke an action on the remote system.
The example I just described is considered 3-legged OAuth 2.0. The curl client example above is using 2-legged OAuth 2.0. When building web applications where you give the user control to authorize access to remote services to another service, this is traditionally done via 3-legged OAuth. This is why they are different. If your remote service supports 2-legged OAuth, then simply run a similar curl against said service and you should receive a similar response.
I hope that helps clarify the outstanding questions on this thread.