Hacker News Reader

Comment by Ruphin | Hacker News Reader

This is nice, but I would never put a piece of code on my property that breaks the user experience (after a few seconds) when a third party service is offline. It's even worse because it causes a highly correlated failure vector across all my products. Imagine your servers going down (for whatever reason) and _all_ my customers calling me because their websites are broken.

Additionally, defaulting to shutting down the app when it can't reach your servers breaks all sorts of offline features an app may have.

I would strongly suggest to default to doing nothing when the script can't contact your servers. Alternatively you let me configure an HTTP endpoint that will be pinged when it can't reach you so at least I am aware the service is disrupted.

View on HN

Hi Ruphin, Frits from Qeys here. I highly appreciate your comment and I totally agree with what you're saying. Not being able to reach our servers should not break your app.

The small piece of code is designed to only invalidate and deny access when a valid response is returned from our servers.

That means that if our service is unreachable you won't be notified about invalid use, of course, but the app assumes the positive and allows everyone access until a valid "denied" response.

Did you experience the contrary, or was this simply not clear from what you read? In that case, I'll try and add that to the FAQ section.

Does this mean that they can access the site for free by blocking qeys.io?

From above, it would sound like it O.o

That solution might sound absurd, but what's the alternative? I implemented my own basic license validation server for an application I wrote, and I ended up doing the exact same thing.

My server may go down every now and then, I don't want to deny access to the application just because my 5$/month server is too busy at the moment..

Yes, it does. Qeys is not designed to deny user access to protected sections of an application, though.

The ideal use case is a web app (e.g. awesome dashboard) you built and is ran on premise on one of your clients' servers. Their dayjob isn't pirating software, so blocking qeys.io probably has not been on their to do list.

But yes, if qeys.io is blocked, no validation takes place.

They would have to instruct all their users to start blocking qeys.io. Looks like this isn't designed to be foolproof, but to deter most from cheating.

I don't think the primary purpose of qeys.io is to block users of the webapp. The purpose of qeys.io is to block customers (not users) from hosting the webapp without your permission.

Here's what I read from the FAQ:

In a very bad scenario where our service is slow, the worst thing that happens is a user being able to use the web app for a couple of seconds before it is denied access.

I understand now that you mean in case the website is an unauthorized copy the end user will be able to use it for a few seconds before it is disabled.

In that case I retract my previous comments, but I would suggest changing the wording in the FAQ here to be more clear. :)

Reminds me of a scenario which leads to "needless" abstractions being created in a project so the absolute on/off dependency on a third party becomes it's own micro-service that the rest of your app calls with an `if (server.isOnline) {do_stuff();}` which leads to massive confusion for developers later wondering if there was really a need for such abstraction or is a mid-level dev was engaged in resume-driven development...

Issues like what you've described -- whether real or perceived -- are the root cause of many code smells.

Boy, do I hate it when I encounter stuff like that. I always try to explain to people that being "online" is not a boolean flag: at most you know that your last request to your crappy heartbeat service have failed. That's it.

You can display a small hint on the UI ("It seems that there's a problem with your connection"), but only an idiot would block users from interacting with the app on grounds of "being offline".

Are you familiar with the video game industry? This tactic occurs frequently.

Reply on news.ycombinator.com