I had similar query last year.
Check Ryan's and Craig's response here --> How to avoid add-on service popup for jive connects api
To make this popup less confusing, we changed the service name to make it more intuitive.
To avoid username password option, there are some auth types in services console which won't require user to add creds, but still show a submit button to authorise.
Thanks I was able to do a customized wording through phrase substitutions, but unfortunately some users are getting the popup for credentials multiple times. Even though I verified through the user's community/apps-admin!input.jspa that the services credentials are there for that user - they are still getting prompted for credentials - so it's not just the first time.
How do I keep that popup from happening after the user has configured the JIVE Connects API webservice.
Can you please help? What am I missing?
Also it's important to mention we have ssl and SSO but how can we utilize that to pass to the app?
This certainly sounds wrong.
Once a user as clicked submit for an app service, ideally the popup should not occur again.
I guess you will have to rely on Jive support to help here
Is there something in my app that needs to store the credentials?
I know we are using signz or authz with HTTP authentication. But we don't have any HTTP headers in the connector. Are we missing something in the app?
Lea Reznik - Sorry coming to this thread a bit late. It looks like you are using Jive Connects (App Services in the Admin Console). Jive Connects is based 100% off of status codes. When a user is challenged with a response to enter their password...Jive Connects will use that password as long as subsequent calls to the webservice return a 20x status code. If the remote service returns something along the lines of 40x then this will prompt Jive Connects to re-issue the authentication challenge to get a new set of tokens.
Some thoughts to consider:
- Can you confirm that your remote service is responding with the correct status codes? Do you have logs that show inbound requests/outbound results for the problematic users?
- Can you confirm that all references to your service in the JS are using the same osapi.jive.connects.xxxx style methods and that the aliases all match?
One other thing. Is your remote service leveraging the authz header scheme? Is it possible that you might have a bug in the validation code that validates the signature. If so, it might be causing the status codes to be erratic, and thus triggering a Jive Connects auth re-request?
Just some thoughts to consider. Overall, sounds like you have thing in Jive wired up correctly for the most part, but this patterns is heavily dependent on the status codes from the external service to be predictable...which is why I'm focusing on that angle.
Thanks a lot for your pointers.
We have been looking in the code and have made few changes in the error handling of osapi.jive.connects.get method.
We are testing this in our UAT environment. After which we have not got the popup but still needs more testing by other users.
Will update on this thread once we confirm our fix.
Can you verify all the above questions?
Does a user property have to be set to know if the user authenticated?
I don't see any user properties getting updated. Should I be?