If you are using or planning to use PLUSManagedGui in your application, this content may not be relevant to you since PLUSManagedGui automatically handles common functionality.
When Internet access is not available and online activation is not possible, manual activation is the recommend method for activating an installation and obtaining a license file from SOLO Server. This involves the end-user copying the activation request or saving it to a file that they would take to another computer with Internet access. They would then paste the request or upload the file to SOLO Server's manual request page, which processes the request and generates a response. The end-user must then copy this response or save it to a file and return to the computer they are attempting to activate. Finally, they must paste in the response or point the application to the file. The application can then parse the response and determine which action to take.
The following demonstrates manually activating an installation, retrieving a license file from SOLO Server, and saving that license file to disk.
The PLUSManaged library has built-in functions for generating requests for the SOLO Server XML Activation Service and XML License File Service web services. Use of these functions avoids having to manually build the web service XML request document. If necessary, further control over generation of the requests may be achieved via the WebServiceCall classes.
The following code snippet demonstrates generating the manual activation request:
This excerpt of code assumes m_License is a reference to an instance of your applications License or WritableLicense implementation class, licenseID is an Int32 object obtained from the user, and password is a string obtained from the user. Now your application may allow the user to copy the request (so it may be pasted to SOLO Server's manual request page), or it may allow the user to save the file (which may be uploaded via SOLO Server's manual request page).
Once the user generates the manual activation request, they must take it to a computer with Internet access where they can paste it in or upload it to the SOLO Server manual request page. If SOLO Server is able to successfully process the manual request it will generate a response that must be taken back to the computer being activated. Otherwise, it will display an error message and it may be necessary for the end-user to contact support for help and possibly have to start the process over.
The above SOLO Server Manual Request link is for use with SOLO Server Shared URL only. If using SOLO Server Custom URL, Dedicated URL, or Self-Hosted, this will need to be updated to point to your specific domain.
Manual request HTML files are convenient for your users since the files can help automate submitting manual requests. In short, these files can be generated easily with PLUSManaged using the ManualRequestFile class. The file will contain the generated request, and can automatically post the request to SOLO Server's manual request page. The code example below shows how you can use this class to automatically save a file to the user's desktop, which he or she may then copy to another computer, and then double click it to process the request using the default web browser.
The code provided above should be modified to specify a file name other than "ActivateXyzProduct.html" (so that it reflects the name of your application instead), and it can also be updated to use a path selected by the user as well (thus allowing the user to use a browse dialog to specify the location instead, if preferred).
If the user is pasting in a response instead of loading a response file, there are a few potential issues to be aware of:
These issues do not occur when the encryption response is loaded from a file.
After the end-user returns to the computer being activated with the encrypted response, it must be decrypted and verified.
In the above code, it is assumed that m_License is an instance of your License or WritableLicense implementation class, and response contains the response received from SOLO Server's manual request page. Once you create an XML document from the license string you can save it to disk. If the response is successfully decrypted and verified, successful will be set to true, and you may then save the value of lfContent to disk as your application's new license file. Otherwise, if the response could not be decrypted or verified or indicates another error, successful will be set to false, and additional details about the error will be available in the m_License.LastError property.
These basic source code examples omit important and necessary error checking for the sake of clarity. Many of the functions used could fail for one reason or another, and it is important that you make sure each function call succeeds before passing the result from one function to another. Otherwise, you may not be able to tell exactly where a problem originated if and when one occurs.
Session code validation to prevents the end-user from processing the same response multiple times, which is known as a replay attack. A random session code is generated and included in each web service request. This session code must be saved somewhere on the system so it can later be retrieved and compared to the session code found in the web service response. If the session codes match then you know the response was the response associated with the original web service request. Otherwise, the response should be consider invalid. Your license implementation class will inherit the CurrentSessionCode property and the ResetSessionCode method from License or WritableLicense. You may use the CurrentSessionCode property to read the session code value (to store a session code after generating a request), and you can set the property to restore a prior value before processing a response. The ResetSessionCode method generates a new session code, and should always be called after successfully processing a response. Additionally, you may opt to be a little more strict and do this when any response processing is attempted, as doing so would be more secure (although it means customers have to generate a new request after each attempt, even if it fails, which could pose some inconvenience depending on how much effort is involved with the customer using a different computer to activate).
PLUSManaged allows activating an application using the Product ID and a serial number pre-loaded into SOLO Server. This method can be used instead of activating with a License ID and Activation Password, and it allows the use of your own activation serial numbers. This can be useful if your customers are already familiar with a certain license key format or if you need to import a list of serials from another system.
The SOLO Server manual topic Importing and Exporting Product Serial Numbers explains how to load a list of serial numbers in SOLO Server. Each time a new license is created for that Product, the next unused serial number in the list will be associated with the license. To issue a serial number to an existing license after uploading the serials, you can simply view the license in SOLO Server and choose the Issue Serial Number option in the Licenses menu.
You must use the mechanism described above to import serial numbers into SOLO Server. Attempting to manually enter a serial number into the serial number field by editing a License in SOLO Server will result in the activation failing with a Response Code of 100.
To activate using the Serial Number, set the SerialNumber property to the value entered by the user (instead of using a License ID) and be sure the ThisProductID property is set correctly. Set the LicenseID property to 0 and the ActivationPassword property to an empty string. Follow the steps above for manual activation.