Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features Requests #4

Open
MostHated opened this issue Oct 6, 2018 · 0 comments
Open

Features Requests #4

MostHated opened this issue Oct 6, 2018 · 0 comments

Comments

@MostHated
Copy link

MostHated commented Oct 6, 2018

Hey there,
Since I kept adding to my previous post I thought it might be best to split it up as some of the things were not related anymore.

Features request 1

The application I have been making I am not even sure if I am going to actually release, I am primarily just trying to learn as much as I can in every aspect of software development, but I definitely want to follow through to the end with it to be as close to production-ready as I can. That being said, if I were to release it, it would come with the software being in "demo mode" if no key was present, it has a config file in which the user would then input their own key once they received it by purchasing a subscription on the site. Because of that, I am wondering if it might be possible / a good idea that when the server side confirm the token, perhaps if the server side also stored a username and an email field which would be tied to a key and on the application side, the user was asked to input their key as well as the user and email used for creation of the key, it might discourage key sharing?

My overall vision is to have a user create an account on my site, purchase their license from my web store, my store will then create the license key automatically and tie that key to the account in which it was created. So then the key is also tied to a transaction id and invoice/order number that the customer receives.

On my own end perhaps upon initial activation of a key, I could somehow trigger that to send a verification email to the email used to create the account and that is tied to the key to verify that the person activating the key is in fact the person attempting to use the key and it would not allow for the initial activation until a response is received from that email verification. Then maybe the MAC address could be recorded and stored and checked against upon startup each time to ensure it's the same machine each time. If MAC != it could reply with a message to contact support to verify that the person trying to activate is the correct person via the invoice/order number they received.


Feature request 2

Single application but with multiple possible features / unlocks. Example the primary application being App1, but App1 might eventually get an update to now be:

App1 |___
          | SubFeature1 - Comes with base application
          | SubFeature2 - Requires upgrade

Upon thinking about it, it seems like there might be at least two decent ways to go about it. If there is already Key1 which is assigned to App1, perhaps SubFeatures could be added to App1 as checkboxes. Say App1 gets downloaded, without a key App1 is in a demo/lite mode. Customer1 purchases a subscription license for App1 which enables Feature1. Down the line, customer might decide they also want Feature2 for App 1. Ideally when the customer upgrades App1 to Feature2, The store could go into the DB and simply turn on Feature2 for the customer, so then next time they open it, when it checks the license is would then see that Feature2 is now activated as well and then internally it just turns on the functionality for Feature2.

That would of course then require the response to be more than just a response 201. So then I suppose that another idea which might work would be an encrypted license.dat file which contains their base App1 key, then when they purchase Feature2 it generates a new License.dat which now contains 2 keys, one for App1-Feature1, and Feature2 and they just swap out their old License.dat for the new one and then I suppose internally it could verify key1 first then send a second request for key2. It's possible but I am not sure if it is a good idea, the license.dat file could also contain the username and email of the purchaser, but it may be better to not include that and upon starting the application it would ask for them to be manually input before it does the verification, so that if the person just has the license but doesn't know the email, they can't even put it in to get to the next step, which could be the email verification that they have to click before inial activation from feature1.

I wanted to see if you had any thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant