I am making the setup of java swing application by using Inno Setup as an exe i am selecting the jar file of my project, I am also adding other necessary resources as folder.
When I am installing the setup on the client side. it is putting the jar and other
resources in program files folder but there client can extract the my java classes
and other resources from jar. I want that client can only use the resources by
application program but he could not extract the resources. How is it possible?
There is literally nothing you can do to entirely prevent someone from extracting the resources.
The best you can do is to make the process a bit difficult; e.g. by storing the resources in the JAR file in encrypted form. The problem is that your program would need to decrypt the resources in order to use them. Someone with sufficient skills and patience can reverse engineer your decryption code and capture the unencrypted resources.
By the way, this is not a Java-specific problem. Any application that you provide to a user as an executable can be reverse engineered ... assuming that the user has the wherewithal to run it in the first place.
The bottom line is that if you are not prepared for the possibility that someone might extract the resources, you should not distribute the executable.
Related
If I have a resource file (mydata.txt) in resources folder (set up as another source folder) of my application. This mydata.txt eventually would be packaged inside root of a jar file (.war) to be deployed to some application server (Tomcat, Jetty, WildFly).
File mydata.txt has some crucial data needed to the application, and this file shall be appended by the application.
To get a file from jar I can use getClass().getResourceAsStream("/mydata.txt") - thus I get this file as InputStream. But there is no way I can get this file as OutputStream and write to it.
All solutions with getClass().getResource() - returning URL are discouraged, getResourceAsStream is always recommended, but it allows only reading, not writing/updating/appending the file.
getClass().getProtectionDomain().getCodeSource() solution is also discouraged to get (write) access to the file.
I could create some file in a temporary directory on Tomcat Server (System.getProperty("java.io.tmpdir") and write to it, but it is nonsense because this file contents is crucial for the application (to write it to tmp dir), besides I need to append file, not create a new one and write to it.
Also, I am not sure that writing to any other directory (other than tmp) of application server is a good idea (please correct me if I am wrong here).
So I come to the conclusion that it is not recommended to save any data to a file in enterprise application, so I shall always use a database instead?
In short: Yes. Beside all you mentioned (which is all correct) the biggest problems are
concurrent access
transaction handling
which both a database serves perfect and with a file approach is just a pain in the ****
In addition to that especially an application server provides you with configuration of connection (and pools) to data sources of any kind, which is really handy in a production environment.
I have developed an application with Netbeans (Using Java, JSP and JQuery) in Windows environment. Now I am ready to transfer the application to a web host so that the application can be available on the Web and I am told that the application would have to be moved to a linux environment (hosting service already bought). Here are my concerns:
How to convert my code to Linux? Is there an automatic tool for this?
How to deploy my application to the server online (what do I need to copy and to what directory on the web?)
My application writes to a directory on c:drive on my laptop, what should I do to make the application write to correct directory a designated directory on the web server?
I have read here and there online but just haven't got specific solutions to this.
How to convert my code to Linux? Is there an automatic tool for this?
One of the Java key features is portability, so as far as you haven't used any OS-specific code like running a program using CMD or similar or a library that is OS-dependant (which is rare in these times but there are some yet), then you don't have anything to do.
How to deploy my application to the server online (what do I need to copy and to what directory on the web?)
You need to generate a WAR file. This file will zip all your web pages (JSPs) and web resources (js, css, image files) along with the Java binaries (*.class) and libraries (that must be on WEB-INF/lib folder).
Since you're working with NetBeans, here's a Q/A to generate the war file: How can I create a war file of my project in NetBeans?
This war file must be placed in the deploy folder of your web application server. Usually, the hosting provides you the tools (generally a link on the web with user and password) to administrate the host, based on this you should ask (or find it by yourself) the option to upload the war file.
My application writes to a directory on c:drive on my laptop, what should I do to make the application write to correct directory a designated directory on the web server?
You need to configure this path as a constant in your application, or even better, configure it in a properties file (or somewhere else) in order to be read and use it by your application easily. Remember that the path should be generic to be supported in almost every OS. For example, if you use a path with name
C:\some\path\for\files
Its generic form will be:
/some/path/for/files
Since you're going to work on Linux, make sure the user who executes the Tomcat (or the web application server you will use on production) have enough permissions to write on that folder. This can be easily done (and somebody here can fix this please) using the chown command:
#> chown -R user /some/path/for/files
Here's another Q/A to manage files and path on Java web applications: How to provide relative path in File class to upload any file?
OK, first a few thoughts:
Convert code to Linux. Once you have your ear of war file, you can just deploy them. It's best if you use UTF8 enconding in your files, specially if you use special characters, but that would be an issue you could test out when you deploy, could also be dependant on the Linux configuration. Having that said, Java is portable and you only have to be sure that the archive you create is compatible with the AppServer that's installed on the Linux hosting. You should get all the information you need about the deployment environment from the hosting site / company.
Deployment will depend from site to site, they should give you all instructions.
Here you might have a problem. I would say that the easiest way is to just map the directory in a properties file and customize it on every machine you use it. That's the easy part so far. However, you should check if your site will give you access to a directory, and be aware of space limitations and cleanup of the files. If you get, let's say, 100MB and you use 10MB a day, you might end up with trouble after 10 days...
I'm currently developing an application for a company which includes livescoring. The XML-files I access (from the net like: "http://company.com/files/xml/livescoring.xml") are not intended to be public and should only known to me.
I was wondering if it is possible for anyone to decode the .apk file and read my original .java files (which include the link to the XML files).
So, I renamed the .apk file to .zip and could access the "classes.dex", which seemed to include the .java files (or classes). Googling led me to a tool named "AvaBoxV2" which decoded this "classes.dex" file. Now I have a folder including an "out" folder where files named .smali exist. I opend one of these with an editor and finally there is the link to the xml file. Not good. :(
Is there a way to encrypt my app or the classes.dex file? I don't want to tell that company, that anyone can access the original xml-files. Maybe signing the app probably helps?
Also, do you know a really noob-friendly tutorial to prepare apps (signing, versioning,...) for Google Market?
Thanks in advance!
The .java source code is not included in the APK.
It is possible to disassemble the Dalvik bytecode into bytecode mnemonics using a tool like baksmali, but there's no way a user can recover the original .java source.
Furthermore, you can use a tool like proguard (included in the Android SDK) to obfuscate your byte code, making it hard to interpret the behavior of the disassembled bytecode.
You can make small tricks too, like storing the link string in some sort of obfuscated form, and then de-obfuscating it at run-time in your app (a simple example would be to use base 64 encoding, but someone could probably reverse that quickly if they wanted to).
That said, it's pretty trivial for someone to run tcpdump and sniff the network traffic between your device and the server, and get the URL that way, so there's no way to completely prevent anyone from getting this value.
Yeah, its impossible to fully prevent something like this. Its the same on a desktop application, or any other application.
As mentioned, obfuscation will help, but people who are persistent can still get past it. Especially for something like a url like that.
One solution of making it much more tricky for hackers is to use PHP on your webserver and some sort of token system to determine if the request is coming from your app or not... That would get a bit tricky though, so I don't really suggest it.
I am doing a project in java and in that i need to add and modify my
text file at runtime,which is grouped in the jar.
I am using class.getResourceAsStream(filename) this method we
can read that file from class path.
i want to write into the same textfile.
What is the possible solution for this.
If i can't update the text file in jar what other solution is there?
Appreciate any help.
The easiest solution here is to not put the file in the jar. It sounds like you are putting files in your jar so that your user only needs to worry about one file that contains everything related to that program. This is an artificial constraint and just add headaches.
There is a simple solution that still allows you to distribute just the jar file. At start up, attempt to read the file from the file system. If you don't find it, use default values that are encoded in you program. Then when changes are made, you can write it to the file system.
In general, you can't update a file that you located using getResourceAsStream. It might be a file in a JAR/ZIP file ... and writing it would entail rewriting the entire JAR file. It might be a remote file served up by a Url classloader.
For your sanity (and good practice), you should not attempt to update files that you access via the classpath. If you need to, read the file out of the JAR file (or whatever), copy it into the regular file system, and then update the copy.
I'm not saying that it is impossible to do this in all cases. Indeed, in most normal cases you can do it with some effort. However, this is not supported, and there are no standard APIs for doing this.
Furthermore, attempts to update resources are liable to cause anomalies in the classloader. For example, I'd expect resources in JAR files to not update (from the perspective of the application) until the application restarted. But resources in exploded JAR files probably would update ... though new resources might not show up.
Finally, there are cases where updating a resource is impossible:
When the user doesn't have write access to the application's installation directory. This is typical for a properly administered UNIX / Linux machine.
When the JAR file is fetched from a remote server, you are likely not to be able to write the updates back.
When you are using an arbitrary custom classloader, you've got no way of knowing where the actual bytes of an updated resource should be stored, and no way of storing them.
All JAR rewriting techniques in Java look similar. Open the Jar file, read all of it's contents, and write a new Jar file containing the unmodified contents (and the modifications you whished to make). Such techniques are not advisable for a Jar file on the class path, much less a Jar file you're running from.
If you decide you must do it this way, Java World has a few articles:
Modifying Archives, Part 1
Modifying Archives, Part 2
A good solution that avoids the need to put your items into a Jar file is to read (if present) a properties file out of a hidden subdirectory in the user's home directory. The logic looks a bit like this:
if (the hidden directory named after my application doesn't exist) {
makeTheHiddenDirectory();
writeTheDefaultPropertiesFile();
}
Properties appProps = new Properties();
appProps.load(new FileInputStream(fileInHiddenDir));
...
... After the appProps have changed ...
...
appProps.store(new FileOutputStream(fileInHiddenDir), "Do not modify this file");
Look to java.util.Properties, and keep in mind that they have two different load and store formats (key = value based and XML based). Pick the one that suits you best.
If i can't update the text file in jar what other solution is there?
Store the information in any of:
Cookies
The server
Deploy the applet using 1.6.0_10+, launch it using JWS and use the PersistenceService to store the information. Here is my demo. of the PersistenceService.
Also, if your users will agree to a trusted applet (which seems overkill for this), you might write the information to a sub-directory of user.home.
I am attempting to store the change made to my application's properties. The .properties file is located in resources package, which is different from the package that contains my UI and model.
I opened the package using:
this.getClass().getClassLoader().getResourceAsStream("resources/settings.properties")
Is there a functional equivalent of this that permits me to persist changes to the Properties Class in the same .Properties file?
In general, you cannot put stuff back into a resource you got from the classloader:
Class loader resources are often read-only; i.e. held in read-only files / read-only directories.
If you got the resource from a JAR file, JAR files are not simply updateable. (To "update" you need to extract the old JAR's contents and create a new JAR with the updated contents. It is all to do with the structure of ZIP files ...)
In some cases, the class loader resource will have been downloaded on-the-fly, and there is no way to push changes back to the place where you downloaded from.
Even if you can update a resource you got from the classloader, it is a bad idea / bad practice.
Doing this "pollutes" the clean application installation with a user's preferences. Among other things, this means that the installation cannot be shared with other users (unless you handle preferences for multiple users ...).
There are security issues with having applications installed as writeable so that embedded preferences can be updated. Think viruses! Think one user who might be inclined to trash another user's preferences!
There are administration issues with having user-specific copies of applications. And if the user has to install his own copy of an app, there are potential security issues with that as well.
There may be technical issues with file locking or caching on some platforms that either get in the way of (safe) updates or make it difficult for an application to load the updated resource without a restart.
Finally, this is NOT the way that system administrators (and educated users) expect software to behave. Java applications should deal with user preferences in the expected way:
You can use the Java Preferences API.
You can write a Properties file containing the preferences to an OS-appropriate user-writable directory.
On Windows, you could use a Windows-specific API to store the preferences in the Windows registry, except that this makes your application Windows dependent. (I can't see any real advantage in doing this, but I am not a Window expert.)
When you wrap your app up as a JAR file, your properties file will be one (possibly compressed) file within that JAR, and it would be a bad idea to try to write to your own JAR.
getResourceAsStream() is meant to open resources for reading, and these can be anywhere on the classpath. You can't write to URLs or inside JARs, you can only write to files, so it doesn't make sense to give you the same API for output.
Find yourself a directory you're allowed to write into, and write your properties there.
It may be a good idea to copy your properties from your installation classpath (possibly inside a JAR) directly out to a file if it doesn't yet exist, as a first operation upon application startup. This will give you a properties file you can write to, yet the master copy of this properties file will come from your project deliverable.
It sounds like you want to store user preferences. Consider using the Java Preferences API for that.
In addition to Carl's answer, if you're going to read and write to this file frequently, and expect that your application will expand in scope, consider whether to go one step (or several steps) further and use a file-based database like SQLite. There are a few JDBC wrappers for SQLite that would allow you to go beyond the basic string key-value lookup that the Java Properties interface provides.
even though writing the file into resources is not good practical, we still need to do it when our application only run in IDEA locally without deployment, then we can do it as below:
URL resource = Thread.currentThread().getContextClassLoader().getResource("settings.properties");
String path= resource.getPath();
OutputStream outputStream = new FileOutputStream(path);
//outputStream write