Help setting up a timed trial?

[Hiblet]

I am new to Keygen, and am still struggling with the concepts. I write Alteryx macros, and I want to implement a system where users download the macro from the Alteryx Gallery, and when they run it for the first time, it creates a new license that expires in 1 month (or whatever period) from the first run. I have set up a Policy, and a License. I am trying to create a new license based on the policy when a user first runs the macro, but I get a 403 error when I try to create the new license. I feel like I am "almost there" but I get no response from the support@keygen.sh address and am unable to progress. The number of configuration options is baffling.

[ezekg]

You can't create licenses client-side without authentication, for obvious reasons. I'd suggest creating licenses server-side using a product token, and then emailing the license key to the user. Another option is using open user registration (i.e. trial sign ups), by setting your account to 'unprotected', and creating an 'unprotected' trial policy, which allows users to create trial licenses via user authentication.

You'd want to make sure all other non-trial policies are protected, so that a trial user can't create a license e.g. for a paid or 'pro' policy. You'd probably also need some sort of Zapier or webhook component to enforce license limits per-user, and e.g. make sure a user doesn't delete their license and create a new one to restart their 'trial.'

FYI, you sent an email to support this morning and yesterday morning, and both went to our spam. Regardless, we do try to respond within 24 hours for paying customers. Support for our free tier is best-effort.

[Hiblet]

Thanks for getting back to me, Zeke. Apologies if I sounded exasperated, it was like that feeling of almost getting all the way there after battling with this, and not quite getting there. I would like to go with Keygen if I can find a way for it to work for us.

There is no plan to have a pay-license as yet. The intention is just for users to be able to use the macro software for free for a period, and after that it locks. If the user wants to cheat the license by re-installing, it is not too much bother to us. We are looking to engage companies who know that they should pay for something that is useful to them.

Alteryx is (mostly) a desktop application and would not be able to listen for a webhook callback.

Ideally the license process would be zero-maintenance from our side. Alteryx macros can be locked and encrypted, so I could (just considering possibilities here) put credentials in the macro and with the admin creds I could create a license for a user, with an expiry that is first-use+duration. I get the feeling you would strongly advise against this, and I understand that. I would agree if this was a core cash generator for us, but really these macros are tasters to engage with potential new customers.

If we moved to a pay system, we could set up a new Keygen user account for pay-only, and figure out a strategy to do licensing with that, where the admin credentials are never existent on the client side.

Our Alteryx macros are non-interactive and designed to be used in the client's workflows as tools. To have a user credential entry pop-up does not work, as Alteryx workflows are all about automation. Our ideal use-case is client user creation of licenses, with admin creds embedded in the encrypted macro. I would be interested on your view on storing admin creds embedded in a locked macro to create licenses, purely for the free-period account. If you could live with that, I would need to figure out how to get those credentials.

Apologies if I came across snotty, and thanks for your considered reply.

[ezekg]

I would never recommend embedding admin credentials in a client-side application, no matter how encrypted or obfuscated. In any client-side application, the credentials eventually need to the decrypted, and a bad actor can and will find them. That's a recipe for somebody — a bad actor — finding the token and thus leaking all of your customer data, and potentially losing access to your Keygen account via a takeover by the bad actor. The only tokens that are meant for client-side use are user and license tokens.

What I would recommend here is setting up a small server-side component that uses a product token to create licenses on behalf of clients. That way, you can interact with that server from your application as you see fit, in a limited fashion (i.e. the server only exposes the license creation endpoint — not e.g. the license deletion endpoint), and remain secure by not leaking your product/admin token. It also gives you room to grow into more sophisticated requirements, such as rate limiting.

E.g. using the server-side endpoint, your application would hit the server endpoint on first boot to create a timed license, and then store that license in the file system (a license file would be a good option here). Then on subsequent boots, your application would query the license in the file system to check the expiry, and eventually stop working after the license expires.

If you have a particular programming language you prefer, we may have an example server for you already here.

[Hiblet]

Thanks for the reply. Agreed, embedding admin credentials does pose risks.

A server side component is not really an option, as Alteryx is a desktop app. I would have to set up a site, and host it, specifically for this. Whilst that is feasible, it is a chunk of work.

What would be ideal is some kind of authorization token that is scoped to only allow client-side license creation. If this were embedded in the flow, at worst, a bad actor could create themselves licenses at will. In our case this is no worse than the current situation of us giving away our macros for free.

Thanks for the language link. Effectively we are similar to Shell/curl/Postman, in that Alteryx can build an HTTP request, payload and headers, and process the response in the workflow. I've got most of that working, the problem is now trying to find a way for users to safely create their own licenses.

[ezekg]

The only way to accomplish this as required would be to subscribe to an Ent tier and use custom permissions for this, generating a product token with only the license.create permission. Right now, custom permissions are an Ent-only feature.

It's not a common use case, but it should work fine, since the token would be scoped to only 1 action.

Related: keygen-sh/keygen-api#314

[Hiblet]

OK, that's fair. We cannot go for that kind of price tag at the moment. This is more of a loss-leader than core business. I really appreciate you taking the time to engage and try to help find a solution, and I hope Keygen has a bucket-load of success.

[ezekg]

Understood. Let me know if you have any other questions. If you want to implement redemption tokens, we'd be open to working with your team on reviewing a pull request. Outside of that, you'll need to pick from the above options. 👍