P
Paul
All,
I inherited a desktop C++ (VC6) application that uses the user's web
browser for output. When the system first wants to display output it
writes a temporary html file, fires up the web browser with an html
page with an applet that opens a socket that listens for messages on a
particular port. The C++ app then sends the temp file name through the
socket for the applet to display. When new output comes along the new
file name gets sent through the socket and the applet updates the web
page (so all of this work is just so that you don't get a new web page
for each output). It uses a similar mechanism to display help (sending
the relevant section number through the socket). The relevant Java
looks something like this:
m_serverSocket = new ServerSocket(m_theApp.m_port);
and then later
clientSocket = m_serverSocket.accept();
Recently the java people decided that connecting to localhost is a
security risk (see http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1),
so that this accept() now throws a security exception. I'm trying to
fix this but I'm not getting anywhere. Here are the things I've tried
and decided doesn't work (feel free to point out mistakes or
misunderstandings on my side, I'm a noob at java):
1) I changed the C:\Program Files\Java\jre6\lib\security\java.policy
file to add "accpet" for localhost:
permission java.net.SocketPermission "localhost:1024-",
"listen,accept";
this works, but I can't use this because a) it isn't safe, b) we
don't want users to have to change their java.policy files and
obviously the installer can't do it
for them.
2) I don't want to sign the applet because this will be really
confusing to users (why should they be asked to trust anything from a
desktop app that doesn't even do
anything over the net?)
3) I've tried passing a command line parameter to the applet in order
for it to use an "application" specific policy file, but it seems that
an applet can't take
the -Djava.security.policy command line parameter.
4) I've read that unsigned applets can (only) open sockets back to the
server from which it was loaded, but I'm not using a web server so
there is no server URL (and
localhost doesn't work).
I'm out of ideas but would love to hear some!
Paul
I inherited a desktop C++ (VC6) application that uses the user's web
browser for output. When the system first wants to display output it
writes a temporary html file, fires up the web browser with an html
page with an applet that opens a socket that listens for messages on a
particular port. The C++ app then sends the temp file name through the
socket for the applet to display. When new output comes along the new
file name gets sent through the socket and the applet updates the web
page (so all of this work is just so that you don't get a new web page
for each output). It uses a similar mechanism to display help (sending
the relevant section number through the socket). The relevant Java
looks something like this:
m_serverSocket = new ServerSocket(m_theApp.m_port);
and then later
clientSocket = m_serverSocket.accept();
Recently the java people decided that connecting to localhost is a
security risk (see http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1),
so that this accept() now throws a security exception. I'm trying to
fix this but I'm not getting anywhere. Here are the things I've tried
and decided doesn't work (feel free to point out mistakes or
misunderstandings on my side, I'm a noob at java):
1) I changed the C:\Program Files\Java\jre6\lib\security\java.policy
file to add "accpet" for localhost:
permission java.net.SocketPermission "localhost:1024-",
"listen,accept";
this works, but I can't use this because a) it isn't safe, b) we
don't want users to have to change their java.policy files and
obviously the installer can't do it
for them.
2) I don't want to sign the applet because this will be really
confusing to users (why should they be asked to trust anything from a
desktop app that doesn't even do
anything over the net?)
3) I've tried passing a command line parameter to the applet in order
for it to use an "application" specific policy file, but it seems that
an applet can't take
the -Djava.security.policy command line parameter.
4) I've read that unsigned applets can (only) open sockets back to the
server from which it was loaded, but I'm not using a web server so
there is no server URL (and
localhost doesn't work).
I'm out of ideas but would love to hear some!
Paul