Java Hardware (Device) IDs
LicenseSpring SDK already provides some preconfigured identity providers, which are described in the section below. If none of the preconfigured Identity providers match desired use case, feel free to make your own implementation of IdentityProvider interface which generates a custom HardwareId.
You can find all preconfigured Identity Providers in module LicenseSpring Core, package
com.licensespring.model as Enum HardwareIdStrategy.
This identity provider will generate unique Identity key per device. That means that each device you are using will have its own unique identity. Identity key is generated based on following 3 hardware components:
- Motherboard
- Processor (CPU)
- Hard disks or similar storage units
Use this strategy if you want to generate one and only one unique ID per device and you are running LicenseSpring on physical computer as opposed to running LicenseSpring on Virtual Machine.
This identity provider is the same as AUTO_HARDWARE_ID, but without disk information. This in in the cases where users add removable storage devices (like smart card reader) and the hardware ID changes.
This identity provider will generate unique ID per Virtual machine running on AWS cloud platform. It will generate unique ID by using Virtual machine ID that is unique for each Virtual machine instance. In order to use this strategy, device which is running LicenseSpring must have Internet access as well as access to IP address 169.254.169.254. This is necessary because in order to retrieve VM ID, Metadata service API running on 169.254.169.254 must be called.
Use this strategy if you are running LicenseSpring on AWS cloud platform and want to generate one and only one unique ID per VM instance.
If using this identity provider you must be sure that LicenseSpring application will be running on AWS cloud platform. This is necessary because in case you are trying to use this identity provider on physical computer then NotCloudPlatformException will be thrown. Also, in case you are trying to use this on Virtual machine that is not running on AWS, WrongPlatformException will be thrown. Unless you are absolutely certain that LicenseSpring will be running on AWS, this strategy should be replaced with AUTO_NODE_LOCK.
This identity provider will generate unique ID per Virtual machine running on Azure cloud platform. It will generate unique ID by using Virtual machine ID that is unique for each Virtual machine instance. In order to use this strategy, device which is running LicenseSpring must have Internet access as well as access to IP address 169.254.169.254. This is necessary because in order to retrieve VM ID, Metadata service API running on 169.254.169.254 must be called. It Also checks for the WEBSITE_INSTANCE_ID environment variable from version 2.4.7 (from version 2.5.2 in AUTO_NODE_LOCK too).
Use this strategy if you are running LicenseSpring on Azure cloud platform and want to generate one and only one unique ID per VM instance.
If using this identity provider you must be sure that LicenseSpring application will be running on Azure cloud platform. This is necessary because in case you are trying to use this identity provider on physical computer then NotCloudPlatformException will be thrown. Also, in case you are trying to use this on Virtual machine that is not running on Azure, WrongPlatformException will be thrown. Unless you are absolutely certain that LicenseSpring will be running on Azure, this strategy should be replaced with AUTO_NODE_LOCK.
This identity provider will attempt to figure out on which type of device you are running LicenseSpring (physical computer or virtual machine). If you are running on physical device then AUTO_HARDWARE_ID strategy will be chosen. If you are running on virtual machine then, depending on which cloud platform you are running LIcenseSpring, either AWS_NODE_LOCK or AZURE_NODE_LOCK strategy will be chosen.
Use this strategy if you are not sure on what type of device LicenseSpring will be running.
AUTO_NODE_LOCK strategy will not throw Exceptions like AWS_NODE_LOCK or AZURE_NODE_LOCK do. But because AUTO_NODE_LOCK needs to figure out which strategy to choose, it takes longer to execute.
This identity provider will generate new identity each time method getKey() is called. This is useful for generating multiple identity keys on one device. This strategy is useful for floating license as identity key is not bound to single hardware/device - so that multiple processes/VMs (or several layers of VMs) will have unique keys - preventing over-usage.
This is the default method used by the Floating Client SDK. Use this strategy in order to completely control how many instances of your application are running. It also requires the cacheHardwareID(boolean) configuration option to be true or a ConfigurationException will be thrown during init.
If none of identity providers matches your use case, feel free to make your own custom implementation. IdentityProvider interface can be implemented in the following way:
