I have an Applet that is required to run with some privileges, meaning a warning message will be displayed when it loads. If the user denies the warning message I would like to redirect to an error page and explain what happened. Is there any way to do this?
I looked in to having a timer running and redirect after a certain time period but that's not that exact and it would be nice to catch the response from the pop-up instead.
The following exception is thrown if the user denies the warning:
java.lang.SecurityException: attempted to open sandboxed jar [jar-file]
as a Trusted-Library
The exception is thrown before reaching the init function.
I looked in to having a timer running and redirect after a certain time period ..
..extend that to add a JS function that cancels the timer, then call that JS from the applet, is about the best protection you can get.
A try/catch on security related matters can work for some JREs that load applet sand-boxed if the security prompt is refused, but other run-times (notably the Iced Tea JRE) will not load the applet at all if the security prompt is refused.
I have an Applet that is required to run with some privileges.. Basically we store a file there, the file can be any file and the size can therefore be any value. The user will choose this file themselves and they can choose anything from a 1kb textfile to a many-gigabyte movie. ..
If the user can be guaranteed to have a 'Next Generation' - Plug-In 2 JRE (mentioned in the applet info. page), it is possible to the use the JNLP API in an embedded applet. The JNLP services provide access to the local disks for a sand-boxed app. See this demo of the JNLP file services.
But there is a slight hitch. There is no option to persist the path to the file chosen by the user. In this lesser security environment, the JRE does not provide a File but instead a JNLP API FileContents object. It will not provide a path and is not serializable. But if the user is willing to choose the file each run, it could be workable.
..and that reminds me. Perhaps a better alternative for launching trusted apps. is to offer a free-floating (applet or) frame using Java Web Start. If the user refuses, it never appears on-screen, but they can click the launch button again any time they like (to be prompted again).
Related
I have a self signed application, when i load it in browser it give this warning (Do you want to run this application) each time. I don't want this pop up to appear. I have tried all the settings in java configure setting.
https://www.java.com/en/download/help/java_blocked.xml
Java has further enhanced security to make the user system less
vulnerable to external exploits. Starting with Java 7 Update 51, Java
does not allow users to run applications that are not signed
(unsigned), self-signed (not signed by trusted authority) or that are
missing permission attributes.
WORKAROUND
It is highly recommended not to run these types of applications. However if you still want to run these apps, run only if you understand the risks and implications.
As a workaround, you can use the Exception Site list feature to run the applications blocked by security settings. Adding the URL of the blocked application to the Exception Site list allows it to run with some warnings.
Steps to Add URLs to the Exception Site list
Go to the Java Control Panel (On Windows Click Start and then Configure Java)
Click on the Security tab
Click on the Edit Site List button
Click Add in the Exception Site List window
Add url to Exception Site list
Click in the empty field under the Location field to enter the URL
I have never used JNLP, and I have no web/war server already running so I will install it from sratch:
Which to use?
GlassFish
Tomcat
Apache
Jetty
Another?
I wonder if someone already using JNLP could make any recomendation for the server.
I just want a blank page with a button in the middle for starting the application nothing more, nothing less.
If you use only JNLP you don't need Java server. JNLP is client side. Simple http server like Apache HTTP Server should be OK. HTTP server will be better solution than use of web container/Java EE server because JNLP (usually) is a static content. Even lighthttpd should be enough.
As already stated any server capable to serve HTTP will do. If your WebStart application is not signed by itself (i.e. you code-signed the corresponding Jar files) you could probably consider to publish the JNLP plus its resources via HTTPS. This way your clients will know that the software they are going to execute came from its rightful origin. Although unsigned WebStart applications are restricted in their privileges on the client's machine it still is a measure to elicit trust in your clients. On the other hand this requires more configuration effort with regard to the server you chose.
If your application will need some extended privileges on the client's machine such as access to the file system then I would recommend that you do sign your jar files to gain the necessary privileges automatically (don't forget to specify them in a element within your JNLP).
These are the default restrictions for unsigned WebStart apps:
No access to local disk.
All your jars must be downloaded from the same host. Note, however, that you can download extensions and JREs from any host as long as they are signed and trusted.
Network connections are allowed only to host from which your jars were downloaded. ("Phone home restriction.")
No security manager can be installed.
No native libraries (not even in extensions).
Limited access to system properties. (The application has read/write access to all system properties defined in the jnlp file, as well as read-only access to the same set of properties as applets
You dont need a server to run JNLP(Webstart).. This is how webstart works
it simply is an application that can be started over the web, this would be the procedure from the user perspective:
user goes to yourwebsite.com
user see's link: run my awesome app
user clicks link, which downloads .jnlp file
user runs the jnlp file through java web start (part of java SE, user requires java runtime environment JRE to run this)
java web start reads jnlp to get information about the server that holds the corresponding application
jar files get downloaded automatically (the first time) and then the application starts
user gets bored and closes application
the next day, user comes back and clicks your link again
application is already downloaded, so it starts right away
user gets bored again and closes your application
1 day later, you decide to update your application and you deploy the new jar file on your
server, replacing one of the old files
after 2 days user clicks your link again
java web start recognizes that the user has a different version, downloads update automatically and starts the application again
...
..
.
I have a Java Applet application. The use case is as follows:
The users invoke a URL which is mapped to a Servlet. The servlet as a response returns a JSP page from which the users can navigate in the UI. The entire UI is made of Swing [basically a JApplet]. The events in the UI are handled in the traditional manner [ActionListeners, SelectionListeners...]. Now I have the following requirement:
There is a file in the server directory that I am supposed to allow the users to download through my application. I need to give the users a link in my UI, the clicking of which will trigger the download.
Can this be done considering the security features of JApplets? Also consider the event handling mechanism of Swing components.
The options for a sand-boxed applet.
There are 2(.2) ways to go (that I can immediately think of).
Use the AppletContext.showDocument(URL,String) method to trigger the download using the browser.
For 'Next Generation' plug-in 2 based applets (1.6.0_10+ in Sun/Oracle's JVM) it is possible to hook into the functionality of the JNLP API of Java Web Start.
The JNLP API provides the ability to access the local file-system in a sand-boxed application or applet. Here is my little demo. of the JNLP API file services.
The JNLP API also provides the BasicService.showDocument(URL) method. This version is slightly superior to the AppletContext equivalent for the fact that it returns a boolean to indicate success/failure. The applet based version might fail, and if it does, it does so silently. See also the demo. of the BasicService.
A trusted applet can use this process.
Pop a JFileChooser to allow the user to decide where to save the File.
If the chooser returns a valid File (indicating the action was not cancelled) proceed with saving.
Get an InputStream from the URL.
Establish an OutputStream to the File.
Read bytes from the InputStream, write them to the OutputStream.
Rinse & repeat till read produces -1.
One of my requirements is, on load of page, a file is to be created dynamically and downloaded at a particular location on the client's machine.
In case the file is already present, it has to be over written.
is there any way where we can access the client's system and store the file at the required folder?
I feel one cannot access the client machine when the code is being executed on the server..
Senorio:
1-User click on generate document then it took template stream data ,req. data file and then save two file into client machine.
2-After that template open and it fetch the data file from same directory.
Please help me on this. This is an SOS!!
There are probably other solutions, I use a signed applet for this purpose.
As always, there are a few caveats though:
You can't "force" anything against the will of the user. Applets may be disabled in the client's browser, or they may not even have Java installed. Or the target directory might not be writeable by the user.Your server should handle cases where the client doesn't have the correct version of the file gracefully.
You can't do this from the server side obviously but you also really can't do this from a client script either. Browser security will prevent a page script from modifying contents of the file system.
Your only options will be to run a third-party browser plugin software that has elevated permissions.
Examples of such are
Java Applets
Java WebStart
Microsoft Silverlight
ActiveX
Each one is different and most require some level of user interaction to confirm that they allow plugins to run with elevated security.
I have a java applet that is downloaded to a user's browser when they visit a webpage and allows them resumable file uploads to my server. Obviously, this requires the applet to access the user's hard disk, which I understand is outside the regular sandbox applets can run in. The user sees a security warning popup which asks for their permission to allow this applet to run.
I have signed the applet using verisign and the link from where is applet is fetched is over SSL with a versigned cert. None of these make the warning go away.
Is there a way to make all warnings go away? Can anyone explain what is going on behind the scenes?
JNLP has a FileOpenService which allows the untrusted Java Webstart applications to show a File Open dialog to the user and access the file the user selected:
http://docs.oracle.com/javase/1.5.0/docs/guide/javaws/jnlp/javax/jnlp/FileOpenService.html
You can't avoid this message, it would be a security issue if you could.
Granting Applets Permission
If you tried to run the applet example, you undoubtedly saw errors when you clicked the Click Me button. This is because the Java 2 Platform security does not permit an applet to write to and read from files without explicit permission.
An applet has no access to local system resources unless it is specifically granted the access. So for the FileUIAppl program to read from text.txt and write to text.txt, the applet has to be given the appropriate read or write access permission for each file.
Access permission is granted with a policy file, and appletviewer is launched with the policy file to be used for the applet being viewed.
What you can do is having a configuration (a policy file) to allow this applet to use some files. But you would have to do this manually (for obvious security reasons). Check the link below.
Resources :
oracle.com - Applets, File Access and Permissions