Provide webhooks for license expiry & resumption

Description

As mentioned in ADDON-47, would like to know when to stop sending requests to instances that are no longer paying, and then resume if they re-license. Seems reasonable.

Environment

None

Activity

Show:
Andy Brook [Plugin People]
June 27, 2018, 8:53 AM

Hi Alexandra,
Awesome. With GDPR and comments below, I'm not sure how viable free cloud addons will be, usually they are provided as is, that doesn't really work for GDPR.

> Given the above, would it be fair to assume that you wouldn't want to remove the current webhooks and instead are requesting an additional webhook for license state?

Alas no.

> In either case, webhooks should follow the same user object model as the REST responses as outlined in the REST docs update.

The webhook structure is not strictly the issue here, its getting the thing in the first place.

I think this issue is a particular 'take' on the problem I expressed initially. It it stands, a webhook would be great to be told when Atlassian axes a host, but what I simply want is a descriptor flag : REQUIRE_LICENSE=true. This case can be linked to the scenario of Atlassian Axing a host, and telling us that it did so, but, doesn't solve the core case of zombie hosts that don't die (we purge data after 30days of non-license, customer jira instance reboots, we get a hook, we setup AC_HOSTS, and repeat, indefinitely * evaluating customers who unlicense but don't uninstall the addon)

1) We don't want to get data for unlicensed customers, we just drop it on the floor anyway, at scale were're just burning IO: If we got 100 high volume customers spamming us with webhooks 24x7, we are directly incurring cost to process that stuff with no tangible benefit. Also, it can take multiple months to figure out who these zombie customers are, and identify them to Atlassian support for manual triage, last time there 60 odd customers which had to be individually contacted....

2) In context of GDPR, a customer without an agreement Atlassian should probably not be send us their data. A customer might be surprised to learn that just installing an addon with webhook support causes all their content to be posted to that vendor...

Regardless of the free addon angle (exactly how many of those are there?!) we only want webhook content when an active license is in place. We are fine with adding a descriptor flag for this, but it STILL needs to be implemented by Atlassian.

This issue as it stands would only address a small part of the webhook problem. Fee free to log a related and linked issue:

"As a cloud addon, for GDPR and general performance I expressly only want to receive hooks from licensed customers"

Alex
June 26, 2018, 7:43 PM

/ - We're looking into this. I suspect that webhooks were designed 'as is' to accommodate for free apps for which we don't generate a license.

Given the above, would it be fair to assume that you wouldn't want to remove the current webhooks and instead are requesting an additional webhook for license state?

In either case, webhooks should follow the same user object model as the REST responses as outlined in the REST docs update.

Andy Brook [Plugin People]
June 25, 2018, 1:11 PM

Ok, so a few years pass, nothing happens. With GDPR, having Jira happily post all webhooks to any installed addon regardless of license status may now be a bigger problem worthy of addressing? I see lots of work planned for PII information removal of REST responses, but nothing about webhooks?

In this case, if an addon has no license, there is no agreement with the customer so we are not officially engaged with the customer, so per GDPR, we shouldn't even be getting that data at all. Does this situation warrant review in light of GDPR?

This issue: as an addon, I want to be able to declare in my descriptor that hooks should only be sent when a valid license is present.

Current outcome, Webhooks leak data to unlicensed addons, which is probably not what the customer is expecting to happen.

Jon Mort
July 1, 2016, 7:45 AM

I would also want this. We are provisioning resources per instance so we would like to know when we can disable them

Assignee

Unassigned

Reporter

Peter Brownlow

Labels

Add-on Type

Cloud