I have an Applet that I would like to convert to a JWS file because of all this problem with compatibility with Chrome (and now, Edge). The problem is that I never used this technology so I would like some help.
Is there a step-by-step guide on doing this conversion? I mean, I have a class that extends java.applet.Applet implementing init and start, how do I change it to a JWS/JNPL class? And can it receive parameters like the applet?
We don't need it to run in the browser, so downloading and executing is fine. But it would be better if the browser executed it right away, instead of the user clicking on file downloaded. Is that possible?
Is there a step-by-step guide on doing this conversion?
The JWS info. page here at SO has all the best JWS related links I could think to include.
I mean, I have a class that extends java.applet.Applet implementing init and start, how do I change it to a JWS/JNPL class?
By Jarring the classes and digitally signing the Jars (if not already done) then writing a JNLP file to launch it (and possibly configuring the server to return the correct content-type for a JNLP file).
And can it receive parameters like the applet?
Yes, they are specified in the JNLP file.
Related
I have an applet that receives an XML that serialized a JasperPrint object and print it using printservices. The applet is signed and the certificate is imported in house.
This applet is in a Web application that call it using javascript and it runs in terminals with Windows XP.
The problem is that when you use the applet always displays the prompt to run the application and users have to confirm to print.
Is there any way around this without ever having to confirm?
UPDATE:
i google the problem and i see that applet is dying (like #user3712670 says),
there are another alternative to run java code on client pc from a web page?
i need to use it locally
Short answer: no.
Any settings for those confirmation dialogs are client-side, so there's nothing you can do in your code or on your server to prevent them.
You might be able to get rid of some of them by making your clients change their security settings, but this is probably not advised. And you probably can't get rid of all of them.
You can check the plugin settings for the particular browser you're running, and you can check the Java security settings from the Control Panel.
The real answer is that applets are a dying technology, and trying to make them work is a bit like plugging up the holes in a sinking ship.
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.
we have this problem: we want to save files or print from java applet in browser, but this could not be easily implemented, as java applets don't seem to have rights for calling OS services. Is there any way to implement these two functionalities (maybe with server help etc.). What would you suggest?
Thank you in advance
For accessing resources outside the Applet sandbox, you'll need to sign your Applet, and set up the access privilieges at a policy file.
Here you can find a quite complete guide on Applets Security.
Well the solution was very simple :). In Netbeans -> Project properties -> Application/Web Start/{check the self-signed checkbox}. That's it with all certifications
Tomas is right. But probably I can suggest you a workaround. You can implement your print through browser. This does not require additional security permissions and applet might be unsigned.
To call javascript API from applet the applet must have attribute MAYSCRIPT and use netscape.javascript.JSObject. Yes, netscape! The name remained as a monument for this died browser.
I would like to create a folder selector for my application which will only run on Internet Explorer Browsers (IE6+).
I would like to get the full folder path a user wishes to use via a HTML browse button or similar and then pass this to my server side application which is written in PHP! This can not be done via JavaScript for security reasons so I am looking for any other alternative that will work.
I had implemented a solution using a Java Applet but this did not work out as it didn't work on IE6, plus the browser security is locked down where I am deploying this app, meaning I am unlikely to get away with an applet.
The current solution is getting the user to paste in the folder location into a textfiel, this isn't acceptable any more.
Any implementation advice welcome!
Thanks all
If your app is IE only you can create a simple ActiveX Control with only one method:
HRESULT BrowseForFolder([out] BSTR folderName);
ATL Wizard will give you major portion of code.
But I would consider using flash for this:
It is more widely used then Java (I
think so).
ActiveX is strongly depends on
browser's security options and more annoying to install.
Your task is rather small, so it can
be implemented without deep skills, if you not familiar with flash