I am loading applet in the browser and I want to delete the cache at the start of an applet. The applet stores its cache information in C:\Users\<username>\AppData\LocalLow\Sun\Java\Deployment\cache. I did not find much information on how to delete the cache using java program. And I referred some link that said to use Config.getCacheDirectory() but no luck on that too.
Please let me know if you have any other approach to delete the cache.
You can't access the file system of the client through an applet. Not unless the applet is signed with a certificate by a trusted authority.
Related
this might be a ridiculous question.
I have a signed applet which only read and write on the client's computer file system.
I can purchase a digital certificate from the Well known authority like Verysign or Thawte etc. to sign the applet.
If i sign applet using above mentioned authority can i get rid of this ambiguous Security verification held by Java Plug-in ?
someone says in SO that you can configure policy file and you can get
rid of this. may i know how ?
Thanks
The best way to get rid of the dialog is to import the certificate into the JRE trusted certificate store. Another solution is to modify the Java policy file.
Just have a look into Oracle's documentation: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdl
I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.
My client wants to use an applet to do drag and drop file transfers from the browser. We have everything working for the most part, but the .java.policy file granting the applet file system access needs to be uploaded to every client in order for the applet to have permission to read/write to the file system.
My technical counterpart at the client has just done some research and wants me to look into the java deployment toolkit (a js library that takes care of deployment instead of using html tags). He wants me to see if I can configure the applet to use a policy file requested from a URL. I haven't been able to find how to do this, which is what I expected, since I think it would be a terrible security risk.
The trouble is that they need to be able to grant the applet read/write file system access, but I feel that requesting a policy file from a URL is a bad idea and I need help explaining why.
So that's my question: is requesting a .java.policy file from a URL even possible? If so, isn't that a terrible security risk?
So that's my question: is requesting a .java.policy file from a URL even possible?
Yes it is, but not in any way that is practical. The thing is:
The policy file needs to be in a certain location on the local file system, in order to work.
Any Java app. or applet would need trust to place it there, or even find out where the right location is.
A Java app. needs extended permissions to be able to import the policy file to where it will have an affect.
If a Java app. has the permissions to insert the policy file, it is already trusted.
If so, isn't that a terrible security risk?
Yes, it would be.
If this applet needs trust, digitally sign it.
Addendum
See Java 7 Update 21 Security Improvements in Detail for more info. on the ever tightening Java security environment.
It is apparently planned to have a future JRE default to maximum security. That would mean that by default, only classes in a Jar, digitally signed by a certificate issued by a Certification Authority (e.g. Comodo $180/year, Thawte $300/year) would ever run. Everything else would be rejected.
I am trying to create an application (in java) to monitor files in Dropbox (File added, File deleted, File modified... etc). I can get my application to generate a https url using the DropboxAPI. The problem is that I have to manually copy and paste the url into a browser, log in on that browser and hit allow. Once they do this once I can easily store the information so they do not have to redo this process. Unfortunately the program does not stay running up and is frequently restarted.
My hope is that it is possible to get past this step since I will have access to the users Dropbox password and username already in the application.
Any suggestions?
When you say "easily store this information", what information are you storing and where are you storing it?
Once you finish the OAuth flow, save the access token somewhere persistent (like to a file or to a database). That way, if your program gets restarted you just load the access token and use that without re-doing the OAuth flow.
In the official Dropbox Java SDK, load your saved access token and then call setAccessTokenPair.
I have written a simple program to upload files to dropbox server, for backup purpose.
If you are looking for an implementation . You may check out the code via https://github.com/Jintian/dropbox.
I was wondering if anybody can show me way to be able to create read file permissions for my java applet.
The exact exception I receive is
java.security.AccessControlException: access denied(java.io.FilePermission filename.pdf write)
I've put f.setReadable and f.setWriteable where f is the file and nothing. A little help please.
There's security limits on what an unsigned applet can do, and one of the things it can't do is access the local filesystem (see here for a full list). You have several options:
Sign your applet. If a user then runs your applet it won't run with any security restrictions. However, signing your applet with a trusted certificate costs at least $100 a year, and if you self-sign then nobody is going to trust your applet. And even if you do sign with a trusted certificate the user might decide not to run it.
Set up your applet with a JNLP file. This will let your applet use the javax.jnlp package. You can then use the FileOpenService and FileSaveService to ask the user to let you read/write one particular file. Alternatively, you can use the PersistenceService to store a small amount of data persistently within the browser.