I have moved on to make my first applet and was zooming thru everything faster then i anticipated and now i have hit a snag. The applet is designed to work in a dynamic environment where it will read a specific folder and all of the files in the sub-folders in that folder. The problem I am having is that once it is established on my test server it gives:
access denied("java.io.FilePermission" "\basefolder" "read")
My research has told me that this is because applets in particular are untrusted to begin with. Unfortunately solutions there are a many i have tried a few but none of which seem to work. I am currently using eclipse for creating my applet. So if i am trying to make an applet that reads and displays information on a website from a dynamic folder on a file server what is the best way to grant these permissions?
..what is the best way to grant these permissions?
The problem is not exactly as you expect. The bottom line is that an applet cannot create a File object on a server (for e.g. to get the file list of a directory). That is not because of permissions, but just the way that files & servers work.
To get the file list will require help from the server. And by 'help' I mean the server providing a file list that the applet can read.
If the server is set up to provide the list, and the applet is hosted from that server, it requires no special or extra permissions.
Related
What you do to get rid of this? I wanted to make a game that is accessible from browser. Then I get error "Your security settings have blocked a local application from running".
I changed browser. nothing.
I added exception in "configure java". Nothing.
I looked internet and looked for "medium" security level but it was removed..
Honestly, I'm not sure. But, I might know what's causing the problem. I'll list most of them here (you can find the full list at What Applets Can and Cannot Do):
Applets cannot access the local file system.
Applets cannot connect to or retrieve resources from a third party server.
Applets cannot load native libraries.
Applets cannot change the SecurityManager.
Applets cannot create a ClassLoader.
Applets cannot read certain system properties.
In summary, don't try to make changes to the user's desktop or the client's windows folder. Have them upload the file instead. Don't try to access .pngs or .json from external servers like google or yahoo either, probably because java can't guarantee them to be safe too. Neither can you load native libraries, so you might want to avoid those if you can, and finally you don't have access to some info in SecurityManager, ClassLoader or some System Props.
If your app violates one of these, Java is likely blocking your app from running. But it all depends on your implementation too. Make sure your browser doesn't block certain applet features (and that java supports your browser, make sure everything is enabled too) and try again.
Or, you can ignore all of that and try making your app privileged. Unfortunately I have very little experience with the process of making your app privileged, but from what I can hear, it'll give your applet a little more room to move in.
I am writing a Java file uploader applet, but I simply could not figure the following issue out. (The uploader is very specialised, therefore we could not just use a stock solution). I have a self-signed applet, which I am trying to test locally, but I cannot get it to read local files. I have Permissions:all-permissions declared in the manifest.
If I add
<param name="permissions" value="all-permissions" />
to the applet tag , it throws
com.sun.deploy.security.BlockedException: User has denied the privileges to the code
If I avoid this, it throws
java.security.AccessControlException: access denied ("java.io.FilePermission" PATH_TO_FILE" "read")
BlockedException is thrown in the first case, even though when the Java plugin asks me about security issues, I always say "don't block", in order for this code to run.
Any ideas how I can test this? Or could you point me to an open source Java uploader applet implementation I could inspect? Of course, the deployed version of this software will be signed with a trusted certificate, but I need a means to test it....
Thank you!
Update
Here is what needs to be done:
Given a web application which we developed, this application needs a lot of small files from the local filesystem. So, we need to iterate over a directory structure and inspect files in order to find those that the web app needs. This is very cumbersome by hand, therefore we need to automate this.
I thought of two other approaches:
JNLP-applet, however, its API can only display a FileChooser for single or multiple files, but not for a directory
A plain old Java client application, which will find the files it needs and upload them to the server via an API. This client can then be launched via Java Web Start.
..Do you have any more ideas?
What you are trying to do is generally frowned-upon as this is exactly how systems are compromised with Java installed. The operation you want to do is privileged, you will need to run your code in a privileged mode, and, most likely, create a policy file to allow this to work on the client machine. There's a short, concise tutorial on http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem.
Now, please, this is actually a VERY BAD IDEA. Is there no way that you could rather write a JavaScript page that will perform this upload via some API call at all? That way, you are not bypassing the browser security to perform the upload.
The Java Applet approach is an out-dated, dangerous and down-right nasty solution, and no amount of signing, policy files or tweaks will make this a safe alternative. I'm a huge Java fan, but if there's one thing that gives me nightmares, it's the Java browser plug-in - there's just never a good reason for using it, not when you consider how incredibly unsafe it is. Of course, don't get me started on Flash...
Your idea of using a plain Java client, loaded via Web Start, seems to be the best solution. That way, once installed, your application would have full access to the underlying file system. Of course, this also opens up the debate of whether this is really a situation for using Java in the first place, but that's a whole other kettle of fish.
to do this you have to sign your applet.
keytool -genkey -keystore myKeyStore -alias me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
A self signed applet working off a local server1 should be able to access the local file-system. It might be necessary to lower the security level in the Java Control Panel. Oracle is in a process of tightening the security of applets, so it will depend on which exact JRE version is loading the applet.
It seems the security environment of an applet loaded off the local file-system is tighter than if it were loaded from localhost. See this answer for details.
I agree with your assessment that the the JNLP based file chooser is unsuited to this task. As you mentioned, it is for working with file resources, not directories. Even worse, I noticed a small applet that I had developed using the JNLP based file open services was throwing NullPointerException while browsing around, with associated odd visual behavior in the chooser itself. Totally inadequate.
As the top poster for applet questions, I strongly actually warn against embedding an uploader in a web page. The biggest problems:
It creates further problems with browser/JRE/JavaScript/applet interaction bugs
It creates a non-resizable GUI. There are ways to create a resizable applet, but last time I checked, they were not reliable across browsers.
So in the end, I recommend using a fully trusted (i.e. all-permissions) app. that uses either the Swing JFileChooser or a variant of the File Browser GUI opened from a free-floating, JNLP launched JFrame. If the use-case is simple enough, we might even be able to dispense with the frame itself, and (visually) go directly to the file chooser.
The 'free-floating' approach will not work in a web-app. that requires JavaScript interaction. If the web-app. requires that, we come back to 'applet', and that is where you'd look to use the doPrivileged(..) functionality you mentioned in a comment. The reason being that if a method is called programmatically by JS, the Java based security manager detects that some frames in the stack are not trusted (the JS), and therefore puts everything back in the sand-box - even if the Java code was originally trusted.
I have been using IntelliJ for a while now and I'm enjoying its suite of features but I'm having a hard time getting the run configurations to work for a java applet. I have a pre-existing Java tool that uses Swing and I'm using the JApplet class to load those GUI objects as an applet. The problem is I have a couple configuration files that I need loaded. I load these from the working directory and from my knowledge, this working directory would normally be the directory in which the applet resides. I think the major problem is IDEA sets the startup variable:
-Didea.launcher.bin.path=IDEA_BIN_DIR
I would like to be able to change this but I am seemingly unable to. I have tried overriding this flag by editing the applets run configuration VM parameters, but IDEA will continue putting the above one in even if I specify something different.
So in short, I'm having a hard time loading a local configuration file because I can't set the working directory for the run configuration in IDEA. Does anyone know how to get around this or know of a better way of running Java applets that use configuration files, in IDEA?
An applet normally runs in a sandbox in a browser, and such an applet can't access the local computer's file system, for security reasons.
Thus it is generally a bad idea to load configuration files from the file system, and "working directory" is not a useful term for an applet.
If these files change seldom (i.e. in principle only by the developer), you can put them to the applet's class files (i.e. in the jar file, or during development in the directory where the classes will be generated), and use class.getResource() or .getResourceAsStream() to load them.
If the configuration files should be definable by the webmaster, put them on the webserver - either at some fixed location relative to getCodeBase() or .getDocumentBase(), or specify them as parameters to your applet tag in the HTML tag.
If these are user specific configuration files (which the applet should be able to write), you either need to store them on the server and retrieve/store after a login (i.e. you need some logic at the server side), or you would store them at the client side.
The current way to do this would be using the JNLP API (in javax.jnlp.*) - there are some interfaces allowing Persistence, or loading/storing data (with the user having a FileChooser). Alternatively, you could sign your applet and request an AllPermission from the user - then you can access the file system.
Sorry, nothing of these answers your original question (I don't use IDEA), but maybe these help you to find another way.
I would like to know if it's possible to edit a file from within the browser. I know where the file is and I know its format. I would like to some HTML5 and JavaScript but have little luck so don't mind using Flash or Java.
The file I would like to edit is the hosts file. C:\WINDOWS\system32\drivers\etc\hosts on Windows XP.
This is mostly for test run of a new breed of AdBlocking so would like to give my browser and the best chance of working. I have Google Chrome Dev opened as ROOT, running on Windows XP.
Java applet with the correct permissions can access the file probably but how easy is it for the user to setup those permissions is a question I can not answer.
Flash is not going to work 100% as it can not be loaded from the internet and access the hard drive at the same time, without going into details you can trust me on that one as the security model simply does not allow it and there is no actual API inside flash to read the file, one can only forward it through to a server(only upload, no download), nothing more (if running from the internet sandbox).
Javascript - not sure, i kind of feel like it can't for similar reasons as Flash but somebody should probably confirm.
The add-blockers usually work as addons to the browser so you should probably do the same as you should have access but then again, you probably won't need it in that case...
In any case, Flash definitely is not going to work.
Java applets can as long as they are signed ..
Follow these intructions to sign an applet.
P.S these instructions are for a linux setup. You might need to set up environment variables in windows.
Jar signing link
so al long as the users allow the applet to run the applet the applet can modify anything on the file sysem and even open connections to other computers.. and most importantly the applet can be hidden in a corner if that is what you wish
Editing local files from a browser, especially a system file, is something that all browser vendors actively try to PREVENT. This is because all the virus makers are actively trying to edit these too!
If you want an ad blocker editing the hosts file to do it is a terrible idea for a number of reasons. First of all it is only going to work on Windows and your ad blocking won't help for Mac and Linux users. Second it will require permissions escalation on Vista and Windows 7. Third it would have to be reliant on something like ActiveX or Java. Fourth the hosts file would eventually get large. Large hosts file slow down internet browsing because you have to do a full lookup every time.
If you want to block ads, block them at the browser level. I hope I have convinced you that modifying the hosts file for this is a bad idea.
So I have created an applet that creates a file on the local hard drive, and eventually uploads it to a CGI that I have created.
When run on IE, the applet works fine, and creates and uploads the file properly.
However, on firefox, I get an error on the Java Console, access denied, showing me that it simply can't create the file. I created the certificate myself, and did not buy one or have it verified through a company.
I need a solution that will work for anybody who potentially uses the applet, meaning the fix can't just be editing my own settings, unless I can do that with every computer that accepts the certificate.
Unsigned applets cannot access local disk on all browsers. It worked for you in IE because I believe that you ran it from file system (not via http). So, the right solution is not to create file on disk. Create content in memory and upload it. But remember: you can connect only to server the applet was downloaded from.
If you really have to create local file you have to sign the applet.
May be, some setting has to be done. One of the reason could be your Mozilla Firefox is not java enabled.
Check the following links :
A fix for Java applets not loading in Firefox
Applet loads but hidden in Firefox
To test whether java is enabled or not in a web browser, click [here]
This bug may be relevant.
It states that Firefox kills java applets that take too long to load. I have an example that works fine when loaded from a local resource but fails when it is remote. Sometimes, reopening the applet can make it work as it appears that it loads more and more of the classes each time.