Cloudflare Workers for Fast, Inexpensive, Lightspeed X-Series Business Rules

A client that operates in a highly-regulated field needed a Business Rule for their Vend / Lightspeed X-Series POS system, and we were able to implement the rule using a Cloudflare worker, making it blazing-fast and extremely reliable, while also reducing the initial cost by 90% and essentially eliminating ongoing costs. It felt great to help improve their business, and I still was paid well for my time, so this was a good outcome all around. I enjoyed it enough that I would like to do more, so if you need Lightspeed Retail X-Series Business Rules please contact me!

A note on terminology: The POS system was created by Vend, which was recently bought by Lighspeed. Rebranding isn’t complete so the product is referred to as both “Vend” and “Lightspeed Retail POS (X-Series)” – which is quite a mouthful. I am used to saying “Vend” so that’s probably what I’ll use the most, but may also use “Lightspeed X-Series” for future SEO.

What are Lightspeed X-Series Business Rules?

Business Rules are web hooks that the Vend platform sends when certain events take place. Depending on the response to the web hook Vend can take certain actions, such as showing a message to the cashier, preventing the sale, and more. Because the POS waits for the rule to finish before continuing rules need to send their response extremely fast, otherwise the Point of Sale system will feel super-slow and broken. Lightspeed X-Series will wait up to 2 seconds for a response from the URL configured, but every effort should be made to respond faster, especially if rules are going to be run when adding items to the purchase. Imagine if waiting two whole seconds between scanning items at the cash!

Cloudflare Workers are the Tool for the Job

The rule we created was able to make all decisions based on the contents of the cart, so when considering how to respond super-fast to a web request containing all of the information needed we realized that Cloudflare Workers are perfect for the job: they’re fast, easy to deploy, and inexpensive.

I also got to work with modern Javascript without worrying about browser compatibility, and that was a breath of fresh air.

Cost Savings

The client had previously set up a similar business, but used a vendor based in the USA to create the business rule. My understanding was that the cost was around US$5,000 to create the rule, and there was an ongoing cost of around US$25 per month per store. With several stores that was an ongoing bill of a few hundred dollars per month.

My work is part of a larger engagement, but it only took me a few hours to learn to build a Cloudflare Worker and program the logic, and both I and the client are in Canada, so my total bill for setting up the business rule was just over 500 Canadian Dollars, savings of over 90%. The worker is running in the client’s Cloudflare account and falls within the limits of the free Cloudflare worker plan, so the ongoing cost is zero. In the future if they grow and exceed the free limits Cloudflare’s worker pricing is essentially a rounding error in the scale of their business.

My CA$500 bill doesn’t include future modifications, so the client may choose to spend more money in the future fine-tuning the rule, or changing the rule as their business needs change, but I don’t see how the total cost could possibly exceed the competing solution.

Business Rule Wishlist

Vend/Lightspeed’s business rules provide an interesting way to extend the Point of Sale system in unique ways. In our situation, because of regulations, we need to limit the amount of certain products that can be purchased in a single transaction – something that I wouldn’t expect to find included by default in a POS system, but so much more is possible. That said, I have a wish list of improvements for business rules. Lightspeed, are you listening?

  • I have been told the POS has an offline mode for situations where internet isn’t available. I would like to see some sort of runtime available to run rules locally. This would let us enforce business rules even if the store’s internet is offline, (some of the client’s stores are fairly remote).
  • Run the “stop” command, or at least the “confirm” command, (which shows a message to the cashier), when adding line items. This would let us prevent an item from being added to the sale, (or let us remove it, then tell the cashier what happened), if the addition of the line item would go over the regulatory limit.

Could I build a business on this?

Building this business rule has me wondering if I could build a business on Lightspeed Retail POS (X-Series) business rules. I’m not sure exactly how it would work, but I could imagine providing access to a library of commonly-needed, pre-built rules for a reasonable flat fee, or maybe a usage-based fee. Maybe custom rules could be built for an hourly rate then run for that same usage fee. There’s some thinking to do! In the meantime I’m interested in building more of these, so if you need business rules, for Vend or any other system, get in touch.

Bug Bounties in a Small Company

The E-mail arrived quietly in our support mailbox. Pretty good English, but clearly not the writer’s first language, and :

BUG : Password Reset Link Not Expire After Mail Change.

Hey!
I found a token miss configuration flaw in…

Ok. Not the biggest deal of all time, but something that should be fixed. The submitter provided really great instructions on how to reproduce the bug and why we should care. I replied thanking the submitter and got this back:

Hi There
Is there any way to give me a bounty ?

Thanks

Baboom. This sounds like the exact situation that Justin Jackson & Jon Buda asked about on this episode of Build your SaaS. We’re a small company. We don’t have a formal bug bounty or vulnerability disclosure program, but I find security fascinating, (at least from the outside), and know bug bounties are a thing. It would be nice to pay a bounty, but how much? What happens next? What if we refuse?

This is what we did, and how it played out.

It’s our first time

My business partner had seen the initial E-mail in the support system so he knew something was up. After a quick discussion about how bug bounties work and asking if he ok with paying something we made the decision to pay small bounties in the neighbourhood of $20 – $50 US per bug, depending on severity, available funds, and how many more reports came in.

I went back to the submitter and said that we could pay but as a very small company with an extremely limited budget he should not expect Apple-style bounties. They were happy with that arrangement, so I fixed the bug.

Then they submitted another but and I fixed that. And another. In all this person submitted 5 “bugs” of varying severity. Some we could barely class as problems but we looked at them all and patched any that needed patching. Some others made us re-think some of the user interface, especially around changing contact or login information, and make plans to change it later.

The reports were both submitted and fixed close together so we lumped everything into one payment. We paid about $100 US for the lot. The submitter asked for payment to go to a random PayPal address that was nothing like the name of the person we were dealing with, then send a screenshot of the completed payment. Pretty sketchy, but they were satisfied.

Writing a Disclosure Policy

I have looked at the bug bounty programs on HackerOne and Bugcrowd, and decided to make a page to point people to when they ask about bug bounties, and to lay down some ground rules, (like don’t DDoS us!). We used Mozilla’s Bug Bounty program and some others from respected companies as inspiration. We included a requirement for detailed reproduction steps, why the bug is actually a problem. This makes it relatively easy to triage any reports we get.

Good thing we wrote a disclosure policy, because as we were finishing up with the researcher another E-mailed us with some bugs, and asking if we have a bug bounty program, and we were was able to respond with a link to the new disclosure page.

Bounty Hunter #2

On Build your SaaS Jon asked if you paid, would you end up on a list of companies that pay, then be flooded with submissions. The answer seems to be at least sort of yes. As we were finishing up with the first submitter another showed up. Submitter #2 had better English than Submitter #1, and was much more thorough. I suspect these two were somehow connected, whether they both post to the same forum or both work for the same person I don’t know, but it felt like we went from a Level 1 pen-tester to Level 2. Submitter #2’s bugs were more creative and more serious than Submitter #1’s. Since #2 showed up just as we were finishing with #1 we were short on cash for bounties, but were honest about it and paid what we could. This seemed well received. I believe we paid about $200 US to Submitter #2.

After once we were mostly wrapped up with Submitter #2 things were quiet for a while, then he submitted one more issue about a week later which we fixed, and since we hadn’t sent the payment yet added to the payment for all of his bugs. Payment was the same sketchy unrelated PayPal + screenshot of the payment method.

Was it worth it?

Short term answer: Yes. At least one of the bugs that Submitter #2 found was serious enough that it warranted immediate attention, so on that level it was worth having someone report it instead of exploit it.

Overall answer: Still yes. For the cost of about $300 US and about a week of my mornings we got outside feedback that made us reconsider some UI decisions from a security standpoint and learned about Content Security Policies and other security headers. Also, the submitted bugs and our knowledge of our systems led us to other related bugs that we fixed as well, so it was a bit like a 2-for-one sale on bug-fixes. And now we have tests written that should prevent these bugs from re-appearing.

Of course I would prefer that we found problems internally before they were deployed, and problems would be discovered at convenient times, but that’s not the real world and I’m happy the problems were found and fixed, and we improved our systems and knowledge as a result.

This all happened back in February and March, and we haven’t had any reports since.

Further Steps

I hear there’s an ISO standard for security disclosure best practices, (apparently ISO 29147 and ISO 30111). I plan on looking them up and do what we can to follow them while balancing that with continuing to improve our product. With a small team it’s always a question of balance, so we’ll keep doing our best!

Has this happened to you?

If I had to bet, I would bet that a lot of small businesses are approached by security researchers this way, but none of us have dealt with them before, we don’t know what to do, and are worried it will be a scam or that we’ll end up on a list and end up spending all our time dealing with bug reports. This feels like something we should talk about.

Opportunity in Tough Times

It is the dawn of the 2009 working year.  After spending a few days celebrating the new year, I spent the morning going through my inboxes, answering E-mail, and seeing what some bloggers out there have written over the past few days.  In NetNewsWire, I discovered Goldfish, by Greg Storey.  Greg suggests that in 2009, a year when many good designers, coders, and everything in between are losing their jobs, those of us who are fortunate enough to have more work than we can handle ourself should spread some of the wealth by hiring or sub-contracting to those who have lost their jobs.

In this new year,  it is simply not going to be enough to just meet your bottom line, but to help others who may not be in a position to be so entrepreneurial or carefree.

There in the comments on Greg’s post, there are commenters who are having a rough time and commenters who are still doing well.  To those having a rough time, reach out to those who are doing well, it is likely that they will have some work that needs doing.

I have work that needs doing, more than I can comfortably do myself.  I do a lot of development in collaboration with designers and occasionally take the lead on various projects.  If you are an (X)HTML/CSS, PHP, or Flash developer, give me a shout.  If you are a designer, I may need your skills too, so you should also give me a shout.  You can use the contact link on this page, (look up), or E-mail me at john at johnbeales dot com.

2009 has the potential to be the worst year ever, but it also has the potential to be the best year ever.  Tough times lead to change and opportunity.  Seize the opportunity.