Urgent: Enigmatic Netscape Security Problem

I have an applet using rmi which produces the attached stack trace in the Netscape Java Console.
The applet offers a remote Object to the server to access (by reference).

I tried to enable the Netscape privileges in my code on applet start up:
But it did not work. I tried combinations of UniversalConnect and UniversalAccept. Did not work. I tried to give the SuperUser privilege but I get a ForbiddenTargetException.

What the h... on earth is going wrong? Does anyone know what the problem is?

Regards Ian

Netscape Communications Corporation -- Java 1.1.5
Type '?' for options.
Symantec Java! ByteCode Compiler Version 210.065
Copyright (C) 1996-97 Symantec Corporation
netscape.security.AppletSecurityException: security.Couldn't connect to '' with origin from 'local-classpath-classes'.
  at java.lang.Throwable.<init>(Compiled Code)
  at java.lang.Exception.<init>(Compiled Code)
  at java.lang.RuntimeException.<init>(Compiled Code)
  at java.lang.SecurityException.<init>(Compiled Code)
  at netscape.security.AppletSecurityException.<init>(Compiled Code)
  at netscape.security.AppletSecurityException.<init>(Compiled Code)
  at netscape.security.AppletSecurity.checkConnect(Compiled Code)
  at netscape.security.AppletSecurity.checkAccept(Compiled Code)
  at java.lang.SecurityManager.checkAccept(Compiled Code)
  at java.net.ServerSocket.implAccept(Compiled Code)
* at java.net.ServerSocket.accept(Compiled Code)
  at sun.rmi.transport.proxy.HttpAwareServerSocket.accept(Compiled Code)
  at sun.rmi.transport.tcp.TCPTransport.run(Compiled Code)
  at java.lang.Thread.run(Compiled Code)
Who is Participating?
msmolyakConnect With a Mentor Commented:
I assume is the machine where you run both your Web server and RMI server (since it is one and the same machine). This is good (that is it is the way it's supposed to be), and the applet should have no troubles connecting to the server it came from.

Looking at the error message it seems you are loading the applet's classes from the local classpath (even though you do not think so) rather than from the Web server. It is easy to verify. Start your browser and clear the cache (to do the clean experiment). Then open Java Console and turn debug mode on (type 9). After that access your applet. The messages on the console will tell you where each of the Java classes comes from. If it says, you are fine. If it says c:\..., then you have a problem.

Check it and post the result.
e4monschAuthor Commented:
Could it be a Netscape Java bug. I'm using the prerelease of Netscape 4.05 with full Java Awt 1.1.5 support.

Regards Ian

3 questions come me in mind. They would clarify the context:

- Does the RMI server run on the same machine as the Web server that delivered the applet?
- Is the applet actually loaded from a server or from the local disk?
- Are you behind a firewall?

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

e4monschAuthor Commented:
1. Yes
2. No local classes on the test computer. Every thing is loaded from server.
3. No

The server object utilieses a client object. Everything works well on Sun Activator/Appletviewer. But not in Netscape.

Regards Ian

P.S. You can use Capabilities API but I do not think you need it in this case. UniversalCOnnect and UniversalAccept shoul do the job. I do not thing the privilege 30Capabilities exists. There is a browser preference signed.applets.local_classes_have_30_powers which will give the applet loaded locally universal connect privilege. But this is not a long-term solution.
e4monschAuthor Commented:
ms...:Yes you are right. It seems as if there has been a local class somewhere in the system. Could it be that, the browser looks for classes in his cache?

After removing the disk cache every thing went ok. But sadly I had to give my code to the professor two hours ago. So now I have given the pro a unfinished software...

Regards Ian

But if the problem is in the cache or CLASSPATH why are you worried? You software should not have anything to do with that.

Browser looks at the cache, than the CLASSPATH on the local machine, then at the ARCHIVE and CODEBASE location from the APLLET tag and probably last at the directory the HTML file with an applet came from.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.