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

Question/Enhancement: License format #3

Closed
Sommerregen opened this issue Feb 8, 2017 · 4 comments
Closed

Question/Enhancement: License format #3

Sommerregen opened this issue Feb 8, 2017 · 4 comments

Comments

@Sommerregen
Copy link

Dear all,

from the Grav commits for Licenses.php I can see that licenses are of the format XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX, where X represents a hexadecimal value. Up to all this allows to store anything with 16 Bytes information.

And here come my questions: Does a license key format exists, i.e., a specification paper what is stored? Does the key contains checksum values (in order to quickly check that the key must be wrong)? And does the key contains some expiration date info (i.e, for trial keys)?

I ask because having a checksum stored with the key is a user-experience enhancement as well as the information what kind of key (expiration date) one has. I also ask because I'll setup a private GPM repository and really want to integrate it as best as I can.

@w00fz
Copy link
Member

w00fz commented Feb 8, 2017

Licenses are really meant to be used only for the Grav marketplace that we are building. We will offer ways to be part of the marketplace so that we can keep one store consistent and available to all.
A License is tied to quite a bit of informations and we purposely not know the specifications of it for security reasons. We are relying on 3rd party services to handle them and have ways to verify that a License matches certain criteria through API calls so that we can react to that.
The built-in License system is also something that overtime could potentially change which is why I advice finding an alternative solution if you do need to have something private and specific for your use. Or you can wait for when we will be able to open up the marketplace.

@Sommerregen
Copy link
Author

That's really bad. But from the point I really find it necessary to allow private repositories in some way. For me it is easy. I almost have a running GPM plugin, that provides the same information than the official ones (I mean https://getgrav.org/downloads/plugins.json ). Writing a client program, that allows to add "third party" repositories is also not the problem. I did that once, but I haven't considered a PR because I know how valuable the marketplace is for the Grav Team.

My question do not refers how we can generate our own valid licenses, it refers to the possibility to verify licenses on the client side (not actual verifying, but at least a check that it isn't misspelled). The same goes for a possible expiration date. Those are data that are really uncritical, but are of any help for the user.

@w00fz
Copy link
Member

w00fz commented Feb 8, 2017

There are no specifications that I know of or that are made public for the License, except that the service we use is using that format. They generate the keys and they associate them.
Any kind of checksum validation just happens by directly asking the service if the provided key is valid.

As you noticed in the GPM Licenses class, we just add a bare minimum amount of checks to ensure that the key matches the standards we figured out ('^(?:[A-F0-9]{8}-){3}(?:[A-F0-9]{8}){1}$'). That really is all we do even with this plugin to verify that a License matches our required standards Licensel::validate($license_key).
GPM will then integrate with this system and properly ask remotely to verify a license before proceeding with installation or updates.

The expiration date is also something we don't have beforehand, the remote verification takes care of checking that.
That said, I can see the expiration of a license being valuable for the user, perhaps something that could be pulled out of the first remote validation and then stored in the grav instance for the user to see.

@Sommerregen
Copy link
Author

Hi @w00fz ,

thanks for the info. I really thought there was some deeper insight in those License Keys. However, if there is no common scheme/ format, then I do not have to care about.

Thanks for all!

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

2 participants