About this plugin
This plugin help to manage your customers licenses, based on uniques user names and serials. This plugin implement a customizable Partial Serial Number Verification System easy to use in your publications.
npCust is the "Keys Verification" part of the plugin. npCust allow you to check the appropiate user names and serial numbers generated before with npRegs. npCust and npRegs working together to enhanced the Verification system.
Thirparty
This plugin are imposible without the aid of this people:
Thanks a lot!
Set the appropiate plugin bytes matrix in order to generate unique serial numbers. PLEASE, TAKE ATTENTION. You need to call this action eleven times in order to complete the bytes matrix. In other case, the related plugin actions cannot work: better said, return an "invalid arguments" error.
Thing on the plugin bytes matrix like the way in that the plugin and your publications work togheter. This plugin can be used for many publications, not only yours publications, but others NeoBookers can use this plugin too: without problems. Because the plugin bytes matrix virtually make the implemented Partial Serial Number Verification System unique to a particular publication.
The plugin bytes matrix is composed by eleven submatrix, that contain everything three numbers, from the range 1 to 255. So, a possible matrix can be established like:
npCustSetMatrix "0" "13" "21" "167" "[Result]" npCustSetMatrix "1" "66" "76" "62" "[Result]" npCustSetMatrix "2" "126" "47" "74" "[Result]" npCustSetMatrix "3" "215" "123" "157" "[Result]" npCustSetMatrix "4" "161" "226" "251" "[Result]" npCustSetMatrix "5" "171" "172" "16" "[Result]" npCustSetMatrix "6" "83" "172" "71" "[Result]" npCustSetMatrix "7" "94" "199" "84" "[Result]" npCustSetMatrix "8" "111" "233" "90" "[Result]" npCustSetMatrix "9" "216" "63" "54" "[Result]" npCustSetMatrix "10" "172" "73" "81" "[Result]"
Since we are refer here to npCust plugin part, we use the appropiate action: "npCustSetMatrix". When you use the npRegs plugin part in order to generate the serial numbers for such publication, you need to use the appropiate action "npRegsSetMatrix" using exactly the same values that the npCust bytes matrix.
The first argument of this action is the index of the matrix, or the "submatrix" element. Remember all are mandatory, so you need to call this action from 0 to 10 index. On every "submatrix" (every action call) you can set the one, two and three bytes that finally conform the bytes matrix.
Of course you can use this plugin in various publications: just change the matrix bytes to make uniques. And over all remember one thing: any change on the bytes matrix make your selled serials invalid. For the other hand, this plugin allow you to publish various releases of the same publication without change the bytes matrix, but the "release base number". We talking about on this below.
Finally the result variable store "True" if everything is OK, or "False" when not, for example, if a byte exced the range (1 to 255) or the index exced the range (0 to 10). In this last case the [LastError] variable store information about the error.
Check the serial sum to find if is valid or not, before to check the user serial. Take a look at this action. Can be used in order to find if a serial number checksum is valid or not, before to call the action that effectively check the serial number.
So, if the serial is not valid, the npCustCheckUserSerial, that really check the serial, is never executed, and nobody can take a look to the executed code. So this action is very very recommended to use.
Only when this action result is "True", you can proced to execute the npCustCheckUserSerial action, in order to find if the registration data is valid or not. In other words, if this action result is "False", never continue executing the npCustCheckUserSerial action.
The result variable store "True" when the serial number argument having a valid serial checksum, or "False" when not.
Check if the provided user and serial conform a valid publication registration data. Please, read before the description of the npCustCheckSerialSum action if you not yet read it. This action check if the customer registration data is valid or not, in other words, if the user name and serial has been generated with the appropiate "keygen" for the release.
This action require three arguments. The first is the release base number. You need to use the same base number, on the publication that act like the "keygen", and on the user publication. This base number is intended to change it when you release a new version of your program: a new version that needed another serial number, making the old ones invalid.
So this plugin allow you to maintain various publication releases with differents base numbers, wich require differents users serials. Think, for example, when you make a mayor update to your program. The objective is that customers with old serials (to old releases) can't registry the new releases. Of course you can send the new serials for the customers who paid for the program updates.
The second argument for this action is the user name. This need to be in the range of 25 to 200 chars. You can divide this string on various parts, and then join to check the serial, or simply use the customer name and email (all together) to supply this argument. The third argument, of course, is the serial number, that you need to send to your customer, joined to the appropiate user name.
The result variable can store one of the following values:
You can act on different ways based on the action result. For example, is not necesary that you advise the user that this introduce a black listed serial. You can save this information to you, and not provide this information to the user. The same way if the serial is invalid: you decide to inform the user or not.
The only result value that guarantee the user name and serial number can be considerer valids is "SERIAL_GOOD", so, in this case, you can procced to save the user registration data, in a way that not need to ask the user again for them (if you not wanted this).
Remember that this plugin is not responsible of how to save the user registratio data, encrypted or not, etc. This is your responsability. If you like, others NeoPlugins like npConf plugin or npCiph plugin can help you in order to working with the Windows Registry and encrypt/decrypt data, for example.
This action help you in order to validate a user name. This need to be in a specific range: from 25 to 200. The result variable store "True" if the user name van be considered valid, or "False" if not. Additionally you can use this action before to check the serial checksum, and before to check the serial number, adding some security to the keys verification system.
Add a stolen serial to the plugin serial blacklist, in order to be detected if used. Call this function the times you need to add a new stolen serial to the serials blacklist. When you check for a valid user name and serial number, the plugin search before on the black list and return the appropiate value when found.
Add the serial number like the "keygen" part of the plugin generate to you. You not need to include the user name, just the serial number, and just like the "keygen" generate by you with the appropiate action of the npRegs plugin, the inseparable partner of this npCust plugin. Take a look at their help for more information.
Just to be clear, here are some important considerations about the npCust and npRegs plugin use. First of all, as you can see, the npCust plugin include the npRegs plugin, or viceversa. Both working together, but cannot be used at the same time.
It's simple: use the npRegs plugin to your keygen publications, the NeoBook made publication used to generate user names and serial numbers to your customers. Then use the npCust plugin in the final publications: never include the npRegs in your final publications.
Doing this way the possible hacker that take your final publication an examine it, never can found the serial keys generator code, because this code is on npRegs plugin, used in your keygen publications, and is not necesary in your final publications.
Due to the nature of this plugin, is absolute highly recomendable that you use the NeoBook compiler option: "Compress and encrypt publication source code". You can set this option on the NeoBook Compiler window.
It's mandatory that you use, in both "keygen" and final publication, the appropiate actions provided with both plugins npCust and npRegs, in order to set the plugin bytes matrix. You can view how to reading the specified actions helps and taking a look at the plugin included samples.
The plugin bytes matrix guarantee (virtually) that every publication use a different way in order to generate and check the user names and serial numbers. So you can use different bytes matrix in different publications, and other NeoBookers too, without possible conflicts or problems.
The plugin bytes matrix need to be set on both npCust and npRegs plugins, using exactly the same numbers. In any case, the other plugin actions check if the matrix as been set, and offer a wrong result (an error) when the matrix is incomplete or invalid.
The plugin bytes matrix is composed by eleven elements, wich have three numbers. So, it's very difficult that other person take the same three numbers, for the same eleven submatrix, and, if you change any number of the bytes matrix, the serial numbers become invalid.
However, you not need to set a different bytes matrix for every of your publication releases. For this the "release base number" enter in action (read below). So, just remember that you need to use a different bytes matrix for every publication that use the npCust and npRegs plugins.
In the same way you need to use the same plugin bytes matrix with both npCust and npRegs plugin, you need to use the same "release base number" with the approipate actions: when you generate a new user and serial number, and when you need to check the user name and serial number.
Supose this scenario: you publish a publication with the base number "1234", and, month later, you publish a new release of your publication. You can choose now between change or not the "release base number", in order to invalidate or not the serials valid to the old base number.
So, your customers can continue using the first publication release, but, need a new serial number in order to register the second publication release. The customer can continue using the first release as usual, but need a new serial number to register the second publication release.
All the NeoPlugins deal with errors in the same way that NeoBook does: when the plugin found an action error the [LastError] variable store information about the error, so you can take care about this variable when execute an action.
But all the NeoPlugins also incorporate an advanced way to deal with possible action errors. You can define a subroutine named OnNeoPluginActionError in order to be executed when some action error are found and you can use this variables inside:
Note that this error handling subroutine are shared for all the NeoPlugins, so you no need to specify a subroutine for every plugin you use in your publication because the same subroutine are recognized and automagically used by every NeoPlugin. Below you can view a sample of this subroutine code:
:OnNeoPluginActionError AlertBox "NeoPlugin Error" "Error [LastError] in plugin: [PluginName]" Return
Also note that the use of this NeoPlugins error handling subroutine is completelly optional. You can continue using the [LastError] variable as usual and even use the both methods at the same time.