Timebomb launch

Opto_Will

I am pretty sure the answer is no but is there currently any way with the Launcher to 'TimeBomb' the executable?

Basically, we have a client that is notoriously bad for payment and has been known to have spontaneous 'dodgy' external access just at about the time we might have had enough and look to shut them off. They seem happy to just click through Revelation's nagware. They then pay their bill when they need something. Then it is rinse and repeat.

We want to be able for them not to be able to start the system if they do so to help us force the issue.
Something like the renewal is due at x so we can set x+30days in the Launcher ini and OpenInsight wont load past that....

DonBakke

You are correct that there isn't such a feature. However, I would not want a feature like that to be dependent upon the launcher since it is easy to circumvent the launcher to run OI. If your customers are online then I suggest building in an API call to homebase that checks to see if the account is active. If not, then display your message and close OI.

Opto_Will

Thanks @DonBakke.
Definately not bulletproof. I was banking on most of our (newer) Customers not knowing they could just run OInsight.exe ;-)

I am intrigued by the API idea. I will discuss it more internally.

DonBakke

@Opto_Will - You have me curious. Am I to understand that the timebomb is always present and would simply be reset for another 30 days once payment was received? How would you plan to update the timebomb settings?

Opto_Will

@DonBakke
Always present? Sort of.

It would definately be controlled manually. I think the idea is to reset that date according to whatever we install that requires a payment that they will try and avoid.
New work? Payment terms + leeway.
New Licence? 12 months + leeway.

Their access always magically reappears when something is needed so we would just reset based on that.
If they DO pay on time then they would need to grant access to revoke the date.
It is possible that such a date would not be set for them I guess (certainly the case for 99.9% of clients).

The only thing about your API suggessstion is that both sides have to guarentee uptime. Can't risk locking out a login request. In that case, have to assume 'success' unless told explicitly in a 200 OK response to 'fail'. If they were smart they would monitor the external calls and then just block the API IP.

Nothing design-wise is set in stone. We are just mulling ways we can try and take back some of the power from the slackers so it isnt drama every time we try and draw the agreed blood from the stone...

DonBakke

@Opto_Will - Since you are willing to have this manually controlled, then you can just as easily build the timebomb within the app and install an RDK to reset the timebox as per your policy. BTW, we've implemented web based authentication but also built-in safeguards in case internet access is unavailable (i.e., we don't necessarily block access). I think in these cases the internal timebox is much further out. Thus, the API based timebox works under the normal timeline (e.g., 30 days) but the internal timebox works under a longer timeline (e.g., 60+ days), thus guaranteeing some degree of control.

We have a client that always prompts the user for a code at a predetermined cycle (much like the Revelation auth code). The app notifies the user in advance so they can make sure they are paid up. The code can be applied in advance to avoid the shutdown.

AusMarkB

We've done pretty much that with just a single field record in a control file. Login always checks and just logs in if all ok.
Warning with login from around 30 days out and once the expiry hits, login screen changes slightly to have extra buttons that allow in some cases, a temporary extension, and also a download new licence from web.
The latter basically just https to a known url, (I think just a text file at the given location), which simply returns an internal date.

Nothing too fancy and generally not applicable to most, but for problem cases, might just be sufficient.

Opto_Will

Its nice to know we all have those special few cases ;-)

Thanks both for the feedback.
I think we dont want to go too fancy, nor bullet proof. We just want to give them a reason to pay. Tip the scales in our favor so-to-speak without building a fortress around them.