Hello,
In this video there is an example of applying the Syncfusion license to a Maui application by pasting the license directly into source code:
Getting Started with the .NET MAUI Carousel Control
But Android/iOS code can be decompiled, correct? Is there any guidance on how to easily provide the license in a secure way?
Thank you for any assistance you can provide.
Starting to get the sense I have stumbled on a good riddle here. đ
Hi Michael,
Yes, Android and iOS apps can be decompiled. Our license key is just a string that needs to be registered before initializing any Syncfusion controls in your application. We donât have any option to secure the registered license key. We have implemented this licensing (key) validation system to avoid customers using our products inadvertently.
You can get the Syncfusion license keys by storing them in a config, json or an app settings file or from an environment variable and use them in their project.
Additionally,
you have the option to store the license key using Azure Key Vault. Please
refer to the following documentation to learn more about this.
Licensing
FAQ â How to securely store and use Syncfusion License Keys in Azure Key Vault
| Syncfusion
But in above
cases also, license keys will be exposed in the front end. As of now we are
aware of this problem and itâs fine to use like that.
If you didnât want this, you can download and use the licensed version of NuGet packages and scripts to avoid using the license key.
Syncfusion provides licensed installer. When you download the licensed installer from your Syncfusion account by logged in using your credential, the license key generation and registration is not required for your projects.
Refer to this UG documentation link for downloading licensed installer.
https://help.syncfusion.com/maui/installation/offline-installer/how-to-download
Installation steps: https://help.syncfusion.com/maui/installation/offline-installer/how-to-install
Please note that, if you are using our components and would like to push your source to a public repository\or any open-source repositories or sharing your source project to your client, you should not push\provide your Syncfusion license keys publicly along with your sources. You should push\provide your source without Syncfusion license keys.
You can
inform the users to sign-up to us (Syncfusion) and get a trial or valid license
to use our products.
You can distribute your deployed applications, but you shouldnât distribute our license keys in a public environment or through your sources.
Let us know any concerns.
Regards,
Kalaiyarasu R
Hi Kalaiyarasu,
Thank you very much for your informative reply! I am nodding along with what you have written. In the case of Azure Key Vault, I actually do use this already with my Blazor application, and this works without any issues there. I also considered this for our mobile application.
However, in the case of a Blazor application, the DefaultAzureCredential for Azure authenticator resolves to the AppService identity, which is defined and assigned in the policies/access of the key vault. In the case of a mobile application, how does this translate to an identity that Azure Key Vault recognizes? I apologize if this is already covered in the informative article that you reference, but I did look and did not see any mobile-specific considerations.
That is, the article you reference works well with web-based applications, but I do not think it applies to mobile-based applications. Please let me know if I have misunderstood this.
Outside of this, if you are saying you have protections in place to identify and mitigate the use of a decompiled key from a mobile scenario, I think this is good enough for me. I will simply put the key in appSettings.json in plain text and read it from there -- making sure not to distribute/publish publicly in any way. đ
Hi Mike,
Azure Key Vault integration using DefaultAzureCredential works seamlessly in web-based environments like App Services, where the app can assume a managed identity that Key Vault policies recognize.
Regarding Mobile Applications:
To avoid hardcoding the Syncfusion license key directly in the source code (which is not secure, especially for mobile platforms like Android/iOS), you can load the license from an embedded resource at runtime. This helps prevent direct exposure in the compiled binary.
Steps:
1. Add the
License File:
2. Load and Register the License at Runtime:
|
using System.Reflection;
string licenseKey; var assembly = Assembly.GetExecutingAssembly(); using (var stream = assembly.GetManifestResourceStream("YourNamespace.syncfusion_license.txt")) using (var reader = new StreamReader(stream)) { licenseKey = reader.ReadToEnd(); } Syncfusion.Licensing.SyncfusionLicenseProvider.RegisterLicense(licenseKey); |
Note: Replace "YourNamespace.syncfusion_license.txt" with the actual fully qualified resource name (typically [DefaultNamespace].[FileName]). You can check this via assembly.GetManifestResourceNames() if needed.
This method keeps the key out of plain source code, offers a bit more obscurity, and is a better practice when distributing apps to stores where decompilation is a concern.
Let us know any concerns.
Regards,
Kalaiyarasu R
Hi @Kalaiyarasu,
Thank you for your confirmation of my understanding that Azure Key Vault cannot be used within Mobile applications, but only Azure Web Applications (such as AppService) where the identity can be applied by policy.
I also thank you for the pointer for using embedded resources. I am already doing this for appSettings.json and can be found here for reference:
From there I store the Syncfusion license key there as a setting.
As such, it appears I am doing everything possible to protect/guard the key as it stands.
Thank you very much for your assistance and support! It is greatly appreciated.
Hi Mike,
Weâre glad to
hear that youâre already utilizing embedded resources for appSettings.json, as
shown in your GitHub reference, to securely store the license key. It sounds
like youâve implemented a robust approach to protect the key, and we appreciate
your diligence in ensuring its security.
Thank you for your kind words about our support. Weâre always here to assist with any further questions or guidance you may need regarding Syncfusion products or integration. Please donât hesitate to reach out if anything else comes up!
Regards,
Kalaiyarasu R