Problems with applet for displaying desktop app's output

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
 
J

John B. Matthews

Paul said:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1 [...]
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?)

I think you should consider signing the applet. Even though it's from
localhost, the applet is accepting an incoming network connection. The
user is being offered a chance to verify that the applet is the one
expected. They only have to accept it once, and you can invite them to
verify your certificate's fingerprint in whatever way makes sense for
your users. Seeing the warning a second time means the applet may have
been tampered with locally, which is exactly what the security patch is
trying to prevent.
 
R

Roedy Green

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).

to get around that, you must sign your Applet. See
http://mindprod.com/jgloss/signedapplets.html

The whole process sounds somewhat convoluted and difficult to
maintain. A simplifying revamp of the whole approach might be better
in the long run e.g.

1. display raw data using an Applet or Java Web Start application.
2. set up a little local webserver that builds the pages.
3. port the C++ code to Java

--
Roedy Green Canadian Mind Products
http://mindprod.com

"If you think it’s expensive to hire a professional to do the job, wait until you hire an amateur."
~ Red Adair (born: 1915-06-18 died: 2004-08-07 at age: 89)
 
M

markspace

Roedy said:
3. port the C++ code to Java

I was going to suggest the opposite. There must be a C++/VC object that
displays HTML. I think getting rid of the clunky browser-applet thing
and just displaying a window directly would simplify things greatly for
the programmer and the user.
 
A

Arne Vajhøj

markspace said:
I was going to suggest the opposite. There must be a C++/VC object that
displays HTML.

There is.

But COM programming in C++ is about 100 times more difficult than
doing stuff in Java.

Arne
 
M

markspace

Arne said:
There is.

But COM programming in C++ is about 100 times more difficult than
doing stuff in Java.


I was thinking something that works like a JEditorPane. Not a COM
object, just an ordinary object that will take a string or buffer full
of HTML, and does basic rendering on it. I think Windows has a help
system with such an object, not 100% sure however.
 
R

Richard Maher

Hi Paul,

8<
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).

Not knowing what your application is doing, or why, I would suggest the
server (C++ or whatever) do the listening on whatever port number you like
and have the Applet connect back to it and request(read) the updates as they
arrive. If you only have a small number of users and don't want to write a
multi-threaded server then you might want to investigate using INETd.

Regards Richard Maher
 
P

Paul

Hi Paul,


8<


Not knowing what your application is doing, or why, I would suggest the
server (C++ or whatever) do the listening on whatever port number you like
and have the Applet connect back to it and request(read) the updates as they
arrive. If you only have a small number of users and don't want to write a
multi-threaded server then you might want to investigate using INETd.

Regards Richard Maher


But isn't this still the applet opening a socket to localhost? Or does
it matter whether it is the Applet or the C++ app that is accepting
the connection?

Thanks for the help!

Paul
 
A

Arne Vajhøj

markspace said:
I was thinking something that works like a JEditorPane. Not a COM
object, just an ordinary object that will take a string or buffer full
of HTML, and does basic rendering on it. I think Windows has a help
system with such an object, not 100% sure however.

The low level Windows API is C and does not have an object.

The high level API's in Windows are usually COM based.

This includes the MSHTML stuff:
http://msdn.microsoft.com/en-us/library/bb508516.aspx

Arne
 
P

Paul

But isn't this still the applet opening a socket to localhost? Or does
it matter whether it is the Applet or the C++ app that is accepting
the connection?

Thanks for the help!

Paul

Tried it, but you just can't connect to localhost from an unsigned
applet. Both "connect" and "accept" throw a security exception.

Paul
 
R

Richard Maher

Hi Paul,

Sorry, I didn't pay enough attention to your File URLS and lack of
web-server.

Ok, clutching at straws, do you have FTP running and accepting requests? If
so set the object/applet/embed tag to use an FTP:// URL to 127.0.0.1 and
that should be the codebase that the unsigned Applet's Socket can connect
back to.

Fingers-crossed!

Cheers Richard Maher

But isn't this still the applet opening a socket to localhost? Or does
it matter whether it is the Applet or the C++ app that is accepting
the connection?

Thanks for the help!

Paul

Tried it, but you just can't connect to localhost from an unsigned
applet. Both "connect" and "accept" throw a security exception.

Paul
 
R

Roedy Green

Tried it, but you just can't connect to localhost from an unsigned
applet.

You can do this:

<applet class="cmp" archive="converter.jar"
code="com.mindprod.converter.Converter.class" width="582" height="552"
alt="You need Java 1.5+ to run this Applet.">
Sorry, you need Java 1.5+ to run this Applet.
</applet>

All you need do is put the jar in the same directory as the HTML page
that invokes it.

This will work for a local file or for an Applet served from the web.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top