I have created a Java applet which uses DLL file included in JSSC library for communication with COM port.
When I run the applet I get security warning saying that application will run with unrestricted access and that information is unreliable or unknown source. Exactly it says:
This application will run with unrestricted access which may put your computer and personal information at risk. The information provided is unreliable or unknown so it is recommended not to run this application unless you are familiar with its source.
And to run I have to click that I accept the risk. This confirming is tiring especially if the applet is run approximately once at 2 min.
I wonder if it is possible to get rid of this confirm dialog by signing this applet with Code Signing Certificate from reliable source.
I have a java web start app that extracts a dll from itself to a temp file, and loads it via System.load("full\path\to\dll").
That completes successfully. However, when I try to invoke the native methods in that dll, I get an UnsatisfiedLinkError with the name of the method.
This is a Windows 7 box, 32 bit 1.7.0_45 (and _51) jre's. This same code works everywhere else except for some computers for 1 customer.
Supposedly the accounts have no local admin permissions (that's normal) and are running Microsoft Security Center Endpoint Protection. Is there some conflict between MS EPP and java's LoadLibrary calls? My google-fu couldn't find it if there is. Or what else could explain this problem?
At first the dll wasn't signed (it's never had to be before), but I tried signing it with our code signing cert to see if that had anything to do with it, but no help.
First of all just put the library file into the application
directory.(ie App Path) Then use System.load(dll_name.dll).It will
surely success. Please check the OS you are using.
For Windows :- Library extension is ".dll"
For Linux :- Library extension is ".so"
So the ".dll" in Linux will give the UnSatisfiedLinkError(Vice versa).
Then also check for the processor Architecture like.
x86
x64
This is a bit of a late followup, but the solution to the problem related to AppSense. It was silently interfering with the load library call because the DLL was being extracted to a temp directory and that violated their policy. The effect was that the library loaded but appeared empty.
We had to sign the dll with our code signing certificate (which the jar's were already signed with), and the customer's AppSense team had to add a rule to allow our signed DLLs to be loaded.
It was a maddening problem. Hopefully this followup helps someone else.
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.
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.
I created a java applet that uploads a file to a server via ftp, it uses an external library by apache, I signed my applet but when I start the applet from the browser I get two security popups, how do I prevent to show or show only one? hello and thanks
this is the example link:
http://frx08.altervista.org/javaftp/
(the second popup says that the code contains signed and not signed code but I don't know why..)
Either:
Make sure all your code is unsigned, perhaps using javax.jnlp available to applets since 6u10. [best route]
Make sure absolutely all your code is signed (and this includes resource files).
The "Trusted-Library" feature allows a signed and trusted library to run with untrusted code. It can be very difficult to write the library securely.