I am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.
Related
I am maintaining a Spring Boot project. There is this code:
BufferedReader reader = new BufferedReader(new FileReader("./setting_mail_sender.txt"));
Where should the file be located in this case?
In 'the current working directory'. And where is that? Who knows!
Whomever wrote that code messed up. It's not a good idea to use the CWD for anything in any java code unless you specifically know you want it. And generally, that's only the case when you're writing command line tools in the vein of the various tools you find in your average linux distro's /bin dir - a rare occurrence, given that the JVM isn't really designed for that kind of thing.
There are 3 different best practices for 'data files' depending on the nature of the data:
Static, unchanging data - as much part of your app as your class files are. These should be loaded with MyClass.class.getResource("name-of-resource.txt") and shipped the same way your classes are. For example, inside the jar file.
Config files. These should usually be in System.getProperty("user.home") - the user's home dir; /Users/yourusername on macs, /home/yourusername on linux, C:\Users\YourUserName on windows. Best practice is to ship a 'template' version of the settings file if relevant in the jar file, and upon detecting that there is no config file present at all, to write out the template (and you load the template in via MyClass.class.getResource). If a template is not a good idea, something in a similar vein. Bad practice is to have the installer do this, and have your app be broken or leave the user having to peruse complex documentation to (re)create the config file. A different way to do it right is to have a config page in your app (a window, menu bar setting, web app thing - something with a user interface) where you can change settings and the config file is simply the way you store that data.
Changing data files. For example, you ship H2 (an all-java database engine) with your app and it needs to write its database file somewhere. This is a bit tricky; user home is not the right place for such data files, but you can't really 'find' the dir where your app is installed either. Even if you can, on non-badly-designed OSes, apps usually cannot (and should not!) be able to write to that location anyway. The location where this data is stored should definitely be configurable, so one easy way out is to require that the user explicitly picks a place. Otherwise I'm afraid you're stuck having to write per-OS code - find /Users/myusername/Library/Application Support/yourappname on mac, which is the right place. As far as I know there is no library to do this right.
None of them involve 'require that the user start the app with the right CWD'. There are good reasons for that: It can be hard to configure, and it's not something users think of to configure. For example, when setting up a java app as a recurring task in windows, you can configure the working dir for such a process, but it's not something that's usually considered as crucial configuration. When running a java app from the command line, who knows what the working dir is. You'll end up with an app that usually works, except in some circumstances when it magically doesn't, and most of your users have no idea that the difference between the magic run that works and the one that does not, is the directory they were in when they started the java app.
If you can edit that code, do so - figure out which of the 3 different kinds of data this is about (sounds like the second bullet: Config stuff, so should be in user home, and the app's name should be part of the file name) - and fix it. for example, that should be:
try (var in = Files.newBufferedReader(Paths.get(System.getProperty("user.home"), "myapp-mail.conf")) {
}
This solves a whole bunch of problems:
Uses try-with to avoid resource leakage.
Reads from user.home, avoiding current working directory as relevant setting.
Actually uses UTF-8 encoding (whereas your code will, at least until java 17, do 'platform default'. It's somewhat unlikely you want that, as it means your config file is not portable; copying it from one computer to another may break things. You presumably don't want this.
If errors occur, the error messages are improved (one of the downsides of the 'old' file API).
If you can't change this code, figure out what the CWD is; put the files there, and ensure that, however you start this spring boot project, you always start it from that directory. If you can't change this code but you can run some code in that JVM, you can print it: System.out.println(Paths.get(".").toAbsolutePath()) will show it to you.
I want to make a executable jar which can run in only one machine.once it is run in any machine it can not be run in another machine.
Means i want to make one license per user type application.
I want to make this application using Java.
Any help on this would be appreciated.
Thanks in advance.
Yes, it's easy. Just grab your hardware informations and generate a hash. This will be synched on each start with a server. It will return a hash which can only be decrypted with the hardware. Then you can create a flag which is available by runtime that it'S "licensed"
Another option:
Remember that JAR files are actually ZIP files, with a different extension. You can store other resource files inside a JAR file, and I believe there is a Java API for retrieving those resource files (I don't remember how that API works). So:
When your customer orders a copy of your application, make them supply hardware information (perhaps give them a little application which harvests the data). Build a JAR for them which contains a resource file, with a hash of the hardware information in that file. When the application starts, retrieve the hardware information and hash it, and compare with the hash in the bundled resource file. If they don't match, exit.
Im pretty sure this is a question that someone already has made, but Im also sure that this has a concept name which I dont know and I would like to get known, therefore I can research more about.
My java app has some setup files, which can be openned as a txt file to manually modify. I would like to prevent those files from being openned manually (by that I mean through the explorer and notepad), I only want them to be modified thorugh the GUI of my application. How people handle this? Some sort of cryptography for each setup file?
I don't think that it is possible to prevent opening a file. But you can put them in system folders e.g. %PROGRAMDATA%. Not exactly what you are asking for but hides them at least from an "average" user and is a common practice.
You could also serialize and deserialize your setup files in binary format.
Another way is - like you proposed - crypting them.
It depends on how secure you want it to be. If you just want to prevent modification by casual users, you could pass some sort of obfuscation over the text to discourage people (e.g. xor with a known value), or you could zip each file.
If you want it more secure, such that even someone with some smarts can't get into them, then you would want to encrypt the files. You could do a search for "java encryption" to see where people have gone with that.
I have been coding for about a month and I have found ways to adapt around ever problem but one. The problem as you can probably see by the title is how to make a way to make game saves. I am currently creating a very simple game that has about 5 classes of my code and maybe 2 of Java Swing GUI.
I know how I would like to go about the saving process but I have no idea how to do it in my code. How I would like to go about doing this is by making the code print a Number or Integer to a file to represent a Level. For example if you completed level 1 the number in the file would be 1. I have tried some templates for this but none of them work.
I understand how to write to a file but my problem is reading it from a jar or even creating a file then reading it from a place on the computer. I need to know how to find a file URL for different computers because some use Docs and Settings and other Users. Please could someone help.
Since the jar is read only, it can only contain the 'default settings'. See this answer for the general strategy to deal with such a embedded-resource.
Speaking of which (embedded resources) see the info. page for more details on how to access them.
Here is an example of storing and reading a Properties file from the 'current directory'.
As mentioned by #MadProgrammer though, it is safest to put the settings file into a (sub-directory) of user.home, as seen in this answer.
But a properties file is just one option. You might also serialize an object, or write the file in a custom format that your app. knows how to read, for the first two off the top of my head.
Besides 'serialize (in some form) in a File', there is also the Preferences API, or for desktop applications launched using Java Web Start, the PersistenceService. Here is a demo. of the service.
I need to know how to find a file url for different computers because
some use Docs and Settings and other Users
The System property user.home points to the user's home directory
File userHome = new File(System.getProperty("user.home"));
I have to create a jar with a java application that fulfills the following features:
There are xml data packed in the jar which are read the first time the application is started. with every consecutive start of the application the data are loaded from a dynamically created binary file.
A customer should not be able to reset the application to its primary state (e.g. if the binary file gets deleted for some reason, the application should fail to run again and give an error message).
All this should not depend on the os it is running on (which means e.g. setting a registry entry in windows won't do the job)
Summarizing I want to prevent a once started application to be reset in order to limit illegitimate reuse of the application.
Now to my ideas on how to accomplish that:
Delete the xml from the jar at the first run (so far I came to the understanding that it is not possible to let an application edit it's own jar. is that true?)
Set a variable/property/setting/whatever in the jar permanently at the first run (is that possible)
Any suggestions/ideas on how to accomplish that?
update:
I did not find a solution for this exact problem, but I found a simple workaround: along with my software I ship a certain file which gets changed after the program is started the first time. of course if someone keeps a copy of the original file he can always replace it and start over.
Any user able to delete the binary file, will, with enough time, also be able to revert any changes made in the jar. When the only existing part of the application is in the hand of the user, you won't able to prevent changes to it.
You can easily just store a backup of the original jar, make a copy, use that for one run, delete, copy the original jar, etc. You would need some sort of mechanism outside the users machine, like an activation server. The user gets one code to activate an account, and can't use that code again.