flowfuse icon indicating copy to clipboard operation
flowfuse copied to clipboard

Improve handling of expired licenses

Open knolleary opened this issue 1 year ago • 13 comments

Description

We don't do much if a platform license expires. We should improve that as we are increasingly providing shorter-term trial licenses to customers.

WE check the license state in two places:

  1. On startup
  2. A daily timer task that runs at 2am. If the license has expired, this task will email the admins of the platform on the day of expiry and every subsequent Sunday.

If the license has expired, then we show this banner to all users on all views:

image

However we do not limit any functionality at this point.

We need to decide how far we want to go on license expiry. Some options are:

  • Remove access from EE features entirely
  • Add intrusive dialog prompts on certain EE-only actions - still allow them to use the feature
  • Add more noisy logging

Open to suggestions on what direction to take in terms of balancing business requirements around trial licenses.

### Tasks
- [ ] Add admin-only warning banner if license expires within 7 days
- [ ] Add daily audit log entry if the license has expired
- [ ] Suspend all instances if license has expired
- [ ] Prevent instance resume if license has expired
- [ ] Prevent resource creation if license has expired
- [ ] Block broker ACL checks if license has expired
- [ ] Ensure applying a valid license then unblocks everything

knolleary avatar Jun 27 '24 09:06 knolleary

If we add the ability to remove features when license expires can we also look at not needing a restart after applying a license?

hardillb avatar Jun 27 '24 09:06 hardillb

This needs to kill resource - otherwise, what incentive does a user have to come back to us? They just get free FF indefinitely?

joepavitt avatar Jul 17 '24 13:07 joepavitt

I believe the consensus here is, if the license expires, we:

  • suspend all instances
  • do not allow suspended instances to be resumed
  • update ACL checks on the broker to cut off devices

We need to make sure all alerting/logging/messaging we provide in the days leading up to expiry make it very clear what will happen.

Will update the task list above

knolleary avatar Jul 17 '24 14:07 knolleary

Yep - seems sensible. Disadvantage being we need existing users to upgrade their FF instances in order to get the changes? Not sure there is much we can do about that?

joepavitt avatar Jul 17 '24 14:07 joepavitt

we need existing users to upgrade their FF instances in order to get the changes?

Right - we cannot remotely disable existing installs.

knolleary avatar Jul 17 '24 14:07 knolleary

I believe the consensus here is, if the license expires, we:

  • suspend all instances

There was some discussion around this back when it was being developed. There was a point raised about NOT shutting down users instances. There may be a good reason (like funding or timing or even a bug) that leads to a licensed expiring. As a user of this product, using it for Production tasks, I would be super unhappy if this happened to me. I recall some discussion around grace period - similar to pretty much how all SCADA systems that are software licenced (as opposed to h/w dongle licensed) work.

Steve-Mcl avatar Jul 24 '24 15:07 Steve-Mcl

I think if the license is over a week out of date it's probably fair to suspend instances.

hardillb avatar Jul 24 '24 15:07 hardillb

I think if the license is over a week out of date it's probably fair to suspend instances.

Respectfully disagree. In manufacturing, it is not uncommon for a product to slip by 1 month due to vacation, illness, budgets, staffing changes, etc, etc. 1 week is super tight to be shutting down production! I can give you examples of other mfg products and their "grace" period if required?

I strongly recommend we are not too harsh in this area.

Steve-Mcl avatar Jul 26 '24 07:07 Steve-Mcl

@Steve-Mcl we offer trial licenses to try the product out, they shouldn't be running production environments on a trial licenses.

Extensions should be the exception, not the default. We can't just give our product away for free.

Note the particular use cases we are considering here are for trial licenses

joepavitt avatar Jul 26 '24 07:07 joepavitt

@joepavitt I just want to call it out to be 100% explicit that this approach does not become the default/defacto approach (for all license types).

We can't just give our product away for free.

I never suggested we do. Only to be mindful 👼

Steve-Mcl avatar Jul 26 '24 07:07 Steve-Mcl

Note the particular use cases we are considering here are for trial licenses

There is no concept of a trial license other than us telling a user the license we have provided them is for a trial. The license itself doesn't identify itself as a trial license.

So anything we do will apply to all licenses.

At some point, we need to stop things running so someone cannot run forever on an expired license. The question of grace period then becomes a philosophical one of - does the grace period apply before or after expiry. By which I mean, if we want to give them 1 month's grace period, then we should start notifying them 1 month before license expiry - not give them 1 month extra for free.

We can refine the specific timings of the tasks I've listed out above, but I think the principle needs to be we stop things running once the license expires.

knolleary avatar Jul 29 '24 08:07 knolleary

Just looking at the list of tasks at the top.

All current methods of suspended an instance will update the database to say it is suspended. This will make restarting instances when a new valid license is added tricky, unless we add a new state/flag to track which should be restarted when a license is applied.

Or is the intent to just allow things to be restarted when the license is applied?

hardillb avatar Jul 29 '24 10:07 hardillb

Or is the intent to just allow things to be restarted when the license is applied?

For a first iteration, yes - it will be a manual task to restart once the new license is applied

knolleary avatar Jul 29 '24 10:07 knolleary

@hardillb as discussed, the changelog/release blog post must include some text about this update. If someone is running with an expired license and they upgrade - they will get shutdown. We need to warn about this and encourage them to get in touch before upgrading.

Also, please check of the items in the task list above as they get covered in your PR.

knolleary avatar Aug 15 '24 12:08 knolleary

Just been looking at what we have already for the warning header.

We already show a warning to admins for the last 30days of the license saying it will expire.

https://github.com/FlowFuse/flowfuse/blob/main/frontend/src/components/banners/LicenseBanner.vue

https://github.com/FlowFuse/flowfuse/blob/1818cf0980a063ee7f2592fccdb3cc8b41b7f729/forge/licensing/index.js#L95

hardillb avatar Aug 15 '24 13:08 hardillb

OK, I think the only technical things left to do if the existing 30day banner is enough?

Is to check blocking the creation of any resources if the license is expired.

hardillb avatar Aug 15 '24 15:08 hardillb

New instances and devices are blocked, can still create teams/applications/users but those can't do anything (e.g. start instances or log into dashboards as they are not running) so not really a problem

hardillb avatar Aug 28 '24 08:08 hardillb