My company recently purchased the Full-Calendar Scheduler addon. Is there a proper way to hide the license key in code? What are good practices for this?
You're right, there's no way to completely hide the schedulerLicenseKey from someone malicious wanting to steal it, however, a thief could much more easily use the universal GPL license key if they wanted a warning-free version of Scheduler, so it's a moot point.
In essence, the actual characters of the license key are not that secret. The license key is mainly used to know when to prompt the developer that they have upgraded past their allowed version upgrade window. Beyond this, it is essentially an honor system. This is why not much attempt is made to encrypt/validate the key.
Use this code.
it works under Scheduler GPL license without charges
$('#calendar').fullCalendar({
schedulerLicenseKey: 'GPL-My-Project-Is-Open-Source'
});
Old question, but since I just came across the same issue, I thought I'd share my 2c. IMHO the best thing to do is never expose the key directly in the code. Instead, store it in some back-end configuration file or even a database field, and read it and assign it dynamically in the front-end. Granted, in the end someone willing enough can still reverse engineer the front-end code and read it (assuming they can log in to the application), but the key will never be that easy to read, as in committed with the rest of the code in your repo.
In short, best practice is to never store license keys in the code.
use 'valid' key, then your problem will be disappeared. I have some case too, then using that valid key, my problem solved.
Related
I'm really keen to use the 2sxc environment on my website for a number of applications.
I'm currently looking at the Mobius forms.
What I'm wanting to do is create a ticket in ConnectWise rather than send an email, using the ConnectWise REST API.
Some of these questions might have obvious answers to someone who has been taught in these technologies, but I'm self-taught. When I went to school I learnt COBOL!
There is c# code in the application, but I can't see how you build and incorporate into the application. I forked the code and it seems to just code with no build.
There are live and staging folders with the same cshtml files. However, it seems a bit random when the live or staging is actually used. For example, I did a quick fix to the _Contact Form.cshtml so to fix the type that meant it always displayed the ReCaptcha warning, and I changed the live version, which didn't do anything, so I had to change the staging version.
I need to update the settings so that configure the ConnectWise API settings, I haven't been able to find where I can do this? I am still looking though.
I also need to store a private key in the settings. Is there a secure way I can do this?
PS. When I get my head around all this I'm happy to be a contributor
welcome to StackOverflow.
I'll try to give you some guidance to help you figure it out
Live and staging are folders meant to let you make changes while the users see the unmodified output. So a host-user sees the files from staging, others see what's in live. When you're done and all is tested, you copy from staging to live. This we call Polymorphism.
Polymorphism applies to both the cshtml as well as the api. So as a host-user, you'll be using staging/api/FormController to save/send.
There is no build process, everything is hot-compiled. That's one of the things that makes 2sxc so amazing. No Visual Studio, DLL or restarting the application ;) You'll love it.
Secure keys: there is no special secure key storage. We usually put it in the App-Settings, just like the MailChimp key you'll see there. We split it into two fields for very technical reasons, because we publish our code on github and that causes trouble when our code has API keys. But you can just use one field, assuming you don't plan on publishing the code on github.
I have an evernote account and I want to write a small application for my personal use. The application will read from the note, use the contents to take some decisions for me and may write back to it as well.
Its perfectly okay if the access is limited to one notebook, or just one note for now. I'm okay to make the note public for now, but I would prefer to keep to private.
For my specific use case, sandbox server won't be of much use. I can go directly to production as it will be a small script only. I have got a developer token but it seems that I can't really read note contents using it. Not sure, if oAuth token is the way to go since I'm not going to share this script publicly.
How should I proceed?
Yes I think that is fine, just be careful not to share the developer token with anyone. I do the same thing for small personal projects that I don't intend to share.
I am in the process of creating a payment gateway for drupal / wordpress / magento. I already have clients who want to use my plugin. Because this is a paid piece of work, I want to protect it from being used on other websites.
I have also seen that many vendors who sell themes, modules and plugins are required to put in the API key.
How can I do the same. What do I need on my server side. I know how to create modules, but I don't know to sell them securely and deliver regular updates.
If there is a book regarding this please let me know.
I'm not familiar with any books on the subject, but I'll tell you what I've seen as one of a founders of a component / plug-in marketplace that has many such plug-ins.
There are a few approaches -
Some plugins do not require an API key at all. Either the plug-in is only available after purchase, or has some limitations on the free downloadable version that encourages people to pay for the commercial version. This approach relies more on people's integrity and low motivation to try and hack the free version into the commercial one, especially if they are not technical users (as many CMS users are).
Set up a check against your server that happens periodically. You do not need a full blown API for this, just set up an endpoint on your server that the plug-in can send the API key and according to the response allows the use of the plug-in. You need to plan it so that this check doesn't happen every time the plug-in is run, especially if it a plug-in that runs on the public site and not only in the administration panel - it will seriously degrade the performance of the site using it and create unnecessary load on your server. Use some kind of time based checked - either absolutely or from the time of the last check.
In addition to or instead of doing an API check, some people will obfuscate their code to make it harder to modify and bypass the check. This often requires that the server has a module installed that can parse the obfuscated files - this requirement often makes it less viable for most people. You can see some examples of obfuscators in another question.
Personally, I lean more toward the first option, as someone determined enough will break whatever protection you put (people break much more complicated solutions in no time). This is one of the problems of delivering source-code instead of binaries (and those are broken just as easily by more experienced hackers). Let those who are willing pay, and the others just let them do what they want as you won't be able to create something truly secure anyway.
I know it may sound silly, but i worked for a client that seems not willing to pay me, but is making money with his website...i still have access to the ftp...so, i'm not going to tear down the website if he doesnt pay, but i would at least protect my code that i gave him...so in case i'm sure that he cant resell or use again...
http://www.zend.com/en/products/guard/
If you code for your client in PHP, this will prevent reverse engineering, and you can set the application to expire after a certain amount of time. There are numerous other licensing options available.
I think you have a deeper problem though, you should really talk to your client or get a third-party mediator to resolve this. At the very least, you should receive a deposit. Contracts will also give you some legal leverage, so you should have signed one before you started work.
what form is your code? html? js? java? c#? you can obfuscate js, for java (or .jar file) you can use the strip/pack tools as detailed here.
in general, obfuscation seems to be pretty effective for all of them (even html, if the bulk of it is generated through scripts :p )
Consider the next poor guy that your client recruits to manage that code... And consider the ramifications - because his impression of you will be based on that code!
If your code is written in ASP.NET, you should obfuscate it (Visual Studio comes with the community edition of Obfuscator), but there're probably better obfuscatation tools than that one.
On a side note, I got my code and last payment actually stolen by a client (the binaries not the code itself, but he managed to disassemble the code with help from a developer. Unfortunately it's too easy with .NET). This is one case where I really regret not obfuscating the code.
First, don't do anything that could be taken as a malicious attack against your client. Messing with their FTP after they have ceased communication could land you in hot water.
Second, if they haven't yet given you a cent for your work then AFAIK you still own the full rights to that work. (i.e. the copyrights on the code etc. you provided) If they use your code, without a license and without paying then they are committing copyright infringement.
This is all legalese, but I'm not a lawyer. Talk to an attorney before acting on copyright.
I have searched through google and SO for possible answers to this question, but can only find small bits of information scattered around the place, most of which appear to be personal opinion.
I'm aware that this question could be considered subjective, but I'm not looking for personal opinion, rather facts with reasons (e.g. past experience) or even a single link to a blog/wiki which describes best practices for this (this is what I'd prefer to be honest). What I'm not looking for is how to make this work, I know how to create a self updating desktop application.
I want to know about the best practices for creating a self updating desktop application. The sort of best practices I'm especially curious about are:
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
How often should you check for updates? Weekly/daily/hourly and exactly why?
Should the update be visible to the user or run behind the scenes from a UI point of view?
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
Should you allow users to update from a central location or only allow updating through the specified application? (for closed business applications).
Surely there is some written rules/suggestions about this stuff? One of the most annoying things about a lot of applications is the updating, as it's hard to find a good balance between "out of date" and "in the users face".
If it helps consider this to be written in .net C# for a single client, running on machines with constant available connectivity to the update server, all of these machines talk to each other through the application, and all also talk to a central database server.
One best practice that many software overlook: ask to update when the user is closing your application, NOT when it has just launched it.
It's incredible how many apps don't do that (Firefox, for example). You just ran the app, you want to use it now, and instead, it prompts you if you want to update, which of course is going to take 5 minutes and require restarting the app.
This is non-sense. Just do the update at the end.
It's hard to give a general answer. It depends on the context: criticality of the update, what kind of app is it, user preferences, #users, network width, etc. Here are some of the options/trade-offs.
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
As a developer your best interest is to have all apps out there to be as up to date as possible. This reduces your maintenance effort. Thus, if the user does not mind you should update.
How often should you check for updates? Weekly/daily/hourly and exactly why?
If the updates are transparent to the user, do not require an immediate restart of the app, then I'd suggest that you do it as often as your the communication bandwidth allows (considering both the update check-frequent but small-and the download-infrequent but large)
Should the update be visible to the user or run behind the scenes from a UI point of view?
Depends on the user preferences but also on the type of the update: bug fixes vs. functionality/UI changes (the user will be puzzled to see the look and feel has changed with no previous alert)
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
same arguments as the previous question
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
if app size is small download it from scratch. This will prevent all sort of weird bugs created to mismatch between the different patches ("DLL hell"). However, this may require large download times or impose heavy toll on your network.
Should you allow users to update from a central location or only allow updating through the specified application? (for closed business applications).
I think both
From practical experience, don't forget to add functionality for updating the update engine. Which means that performing an update is usually a two step approach
Check if there are updates to the update engine
Check if there are updates to the actual application
Do you force an update if the clients
software is out of date, but not going
to break when trying to communicate
with other version of the software or
the database itself? If so how do you
signify this breaking change?
A common practice is to have a "ProtocolVersion" method which indicates the lowest/oldest version allowed.
The "ProtocolVersion" can either supplied by the client or the server depending on the trust level you have between the client and the server. In a low trust level it is probably better to have the client provide the "ProtocolVersion" and then deny access server side until the client is updated. In a "high trust level" scenario it will be easier to have the server supply the "ProtocolVersion" it accepts, and then all the logic for adapting to this - including updating the client application - implemented in the client only. Giving the benefit that the version check/handling code only needs to be in one place.
Do not ever try to force an update unless your lawyers demand that. Show the the user a update notification she can either accept or ignore. Try not to spam the same version too much is she rejected it. The help her make the decision, include a link to release notes or a short summary of changes.
Weekly would be a good default update check interval but let the user choose this, including completely disabling update check from the web. Do not check too often because she might be on an expensive mobile data plan, or she just doesn't like the idea of an application phoning home.
The update check part should be completely silent. If an update was found, display a notification for the user. During download and installation, show a progress bar.
To keep this simple, notify the user about any newer version. If you do not want to annoy them with frequent updates including just a few minor bug fixes, do not release every minor version at the download location watched by the update checker
Maintaining patches for all previously released versions is too much work. If the download size becomes a problem, figure out some other way than patches to make it smaller (7-zip compressed self-extracting exe, splitting the application to multiple MSI packages that have independent versions etc)
Two more things:
Do not implement the update engine as a process that is constantly running in the background even when I'm not using your application. My PC already ~10 such processes hogging resources, which is very annoying.
When updating the update engine itself, on one hand you need to have the engine running to show the installation progress UI but on the other hand the update process must be closed to avoid the reboot that would result from the exe file being locked. There are a number of things like running a helper program from %TEMP%, using Windows Installer restart manager, renaming the updater exe file before starting the installation package etc. Keep this in mind when architecting the update engine.
Do you force an update if the clients software is out of date, but not going to break when trying to communicate with other version of the software or the database itself? If so how do you signify this breaking change?
Ask the user.
How often should you check for updates? Weekly/daily/hourly and exactly why?
Ask the user.
Should the update be visible to the user or run behind the scenes from a UI point of view?
Ask the user.
Should you even notify the user that there is an update available if it is not a major update? (for instance fixing a single button in a remote part of the application which only one user actually requires)
Ask the user (notice a trend here?).
Should you try to patch the application or do you re-download the entire application from scratch Macintosh style?
Typically, patch, if the application is of any significant size.
As far as the "ask the user" responses go, it doesn't mean always prompt them every single time. Instead, give them the option to set what they should be prompted for and what should just be done invisibly (and the first time a given thing occurs, ask them what should be done in the future, and remember that). This shouldn't be very difficult and you gain a lot of goodwill from a larger portion of your user base, since it's very hard to have fixed settings suit the desires of everyone who uses your app. When in doubt, more options are better than less - especially when they're the kind of option that's fairly trivial to code.