Back to all discussions

  •   over 10 years ago

Why validate the Hipchat integration installation capabilities url?

The Installation section of this doc (https://www.hipchat.com/docs/apiv2/addons) says:

> It is recommended your integration access the capabilities URL to verify the URL is valid, and the application name matches the expected application name.

I'm seeing when I install my integration the capabilitiesUrl POSTed back is always:

https://api.hipchat.com/v2/capabilities

I understand you might want to validate legitimate installations vs spoof installations, but I don't see the point in requesting that url. What would requesting that url 'validate'?

Can anyone provide any added explanation?

Thanks

  • 3 comments

  •   •   over 10 years ago

    It's a good idea to verify that you can reach the server. When dealing with HipChat in the cloud that's not likely to be a problem but if the HipChat instance is a HipChat Server installation behind a firewall, it may not be reachable from your addon.

    Also, since the Atlassian Connect framework is supported by many Atlassian products it's also a good idea that you verify that your addon is being installed in a HipChat instance by checking the application name.

    These are mostly just sanity checks on the installation step.

  •   •   over 10 years ago

    Thanks for the response.

    I can see if the server install of hipchat is inaccessible the registration should not respond with a 200. However I've only tested with the cloud version and I notice that times out the install after 5 seconds. So making requests and validating don't have much time to do their work if things are slow on the network...

    I'd have to set a very short timeout on my request back to the capabilities url to make sure I can respond within 5 seconds.

    I'm not familiar with non-cloud hipchat. I'd guess that I'd rather just not deal with non-cloud installs for the time being because they're probably going to have firewall issues with external services calling into their api server?

  •   •   over 10 years ago

    I agree that the timelimits can make this a bit challenging. Nevertheless, 5 seconds should be sufficient time to fetch the capabilities URL, perform some simple sanity checks and store URLs for future use.

    We normally use the various URLs fetched from this capabilities URL, notably the API URL and the oauth2Provider URL in subsequent operations. This gives you some future-proofing if these were to change. As you note, however, these locations are fairly stable.

Comments are closed.