Getting around Applet security

This is not meant as a double-post but I had started a new question on another thread and I feel that it should be it's own post. The thread can be found: http://forum.java.sun.com/thread.jspa?threadID=5185692

It has been awhile since I have worked with Applets (and the first time dealing with Applet security problems) so perhaps I can explain what I am trying to do and see if there are any suggestions. In the enviroment the applet is stored on a SuSE server with JSE 1.6 (no JEE application server) and most clients are using Windows XP with IE and JSE 1.4.2. Alongside the applet there are xml files stored on the server that act as config files that describe the different GUI configurations of the applet. I am reading the xml files using a URL connection from the applet and being parsed with the built in SAX parser but as posted above I keep getting Permission exceptions on the client. I have come up with a few workarounds for this problem, please let me know any are good solutions or if you have any other suggestions:

1. Signed applet, I am still unsure if this will work because does this not just allow the applet to access the client's machine and not the host? Also this would not be a perfect solution because the maintainers of this applet would have to resign the applet in the future when it expires.

2. Combination of applet, server ran application, (and probaly a Perl script to start the application). I would have the application handle all of the parsing and pass the information to the applet through either a socket connection or using RMI. However I am unsure if this will create further security problems.

3. Similar to the method above but instead of a socket connection I would have the application create the GUI and serialize the object then stream the object data to the applet with a URL connection. Of course I would have to make sure that the object data has the correct permissions set and some sort of "trigger" to let the applet know when the data was ready.

These are some ideas that I have come up with, please let me know if there is a method that would be easier/more secure.

-Jordan

Message was edited by:

jwarzech

[2235 byte] By [jwarzecha] at [2007-11-27 8:17:27]
# 1
Applet and server, and don't let the server do anything destructive.
-Kayaman-a at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 2
I don't think this is an Applet Security problem associated with accessing the xml files on the server using URL connection. This will not in itself produce the exception unless the files are on a different server to the one the Applet was loaded from.
sabre150a at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 3

According to http://java.sun.com/sfaq/, There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.

I believe that if you use Applet.getCodeBase() you can get the directory containing the applet, and using that, you can specify exactly which files you want.

RATiXa at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 4

I am working on a similar application to the one you are describing right now and we found that option 2 that you specified was the better choice.

Option 3 is a poor choice because you would be serializing objects across different JRE versions and that is just asking for trouble.

Option 1 MAY solve your problem but I doubt it.

I just have my server parse the XML descriptor files and then pass a data collection of the contents in the XML to the applet. The applet uses the Elements in the collection to dynamically build the GUI.

However if you want some advice, if it is not too late in your project I sincerely reccomend that you move from applets to WebStart.

It is too late for me! ^_^

maple_shafta at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 5

> According to http://java.sun.com/sfaq/, There is

> no explicit support in the JDK applet API for

> persistent state on the client side. However, an

> applet can maintain its own persistent state on the

> server side. That is, it can create files on the

> server side and read files from the server

> side.

>

> I believe that if you use Applet.getCodeBase() you

> can get the directory containing the applet, and

> using that, you can specify exactly which files you

> want.

Accessing the XML file isn't my problem it is accessing the parser. I can't access the parser on the server and it is not an option to change the policy file on all clients to allow to use their JRE's parser.

jwarzecha at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 6
I would include the javax.xml.parsers classes with your applet in that case.Still, I don't see why using a SAX parser would cause permissions trouble.
RATiXa at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 7

> I would include the javax.xml.parsers classes with

> your applet in that case.

> Still, I don't see why using a SAX parser would cause

> permissions trouble.

I think it has to do with the Applet accessing a non-standard library. I get a ProperyPermission excetion for reading org.xml.sax.driver

jwarzecha at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...
# 8

> > I would include the javax.xml.parsers classes with

> > your applet in that case.

> > Still, I don't see why using a SAX parser would

> cause

> > permissions trouble.

>

> I think it has to do with the Applet accessing a

> non-standard library. I get a ProperyPermission

> excetion for reading org.xml.sax.driver

Well i don't know about all that, but what I am trying to tell you to do is to parse your XML on the server and then send the results to the applet.

Can you give me any business or technical reason for why you cannot parse the XML file on the server?

maple_shafta at 2007-7-12 20:02:37 > top of Java-index,Java Essentials,Java Programming...