# Netscape 6 - does anybody know a hack?

J

#### jackh

Hi,

I just discovered that the new Netscape 6 browser is 'suddenly' not allowing remote applets to access remote resources, such as TCP/IP
connections. This is because of applet signing, which is a feature available in the Java 2 (ver. 1.3) toolkit. It seems to be rigidly enforced in Netscape 6, so I can still use appletviewer to use the applets, but when tried with Netscape 6 it claims security violations and quits. (I could have sworn that I was getting access to the applets a few days ago with Netscape 6.) I can still use the applets with Netscape 4.72. Does anybody know how to get around this?

BTW, Netscape 6 is extremely buggy, and seems to have fewer features - it feels like it has been steered more by the commercial AOL interests
than the GPL developers. In the mid 90s AOL introduced the worst users and abuses to the internet, remember publicly writable FTP sites, and when spam got a user cut off? Are they doing it again with Netscape?

Note: You can run both the new and old browsers on the same machine at the same time. But, I don't suggest deleting the old one just yet.

Hugh

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

H

#### Harald Albrecht

> I just discovered that the new Netscape 6
> browser is 'suddenly' not allowing remote
> applets to access remote resources, such as
> TCP/IP connections. This is because of applet
> signing, which is a feature available in the
> Java 2 (ver. 1.3) toolkit. It seems to be
> rigidly enforced in Netscape 6, so I can still
> use appletviewer to use the applets, but when
> tried with Netscape 6 it claims security
> violations and quits. (I could have sworn that
> ago with Netscape 6.) I can still use the
> applets with Netscape 4.72. Does anybody know
> how to get around this?

Jar up your classes and drop the jar file into
your JRE's extension directory. The extension
directory is usually called 'ext/' and is below
the 'lib/' directory. Make sure that
'lib/security/java.policy' grants all
permissions to all Java extensions lurking in
the extensions directory:

grant codeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission; }; However, this is only a "hack" to get things working. In the long run I would suggest to separate the classes or packages that need privileges and only store them locally in the extension directory. Although you have now to "install" those classes explicitely in the appropriate directory, you can skip the signing step. Harald -- Harald Albrecht Chair of Process Control Engineering RWTH Aachen University of Technology Turmstrasse 46, D-52064 Aachen, Germany Tel.: +49 241 80-7703, Fax: +49 241 8888-238 _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc H #### Hugh Jack Hi, Here's some fuel for the conspiracy fire, I just found that the applets will run under Netscape 6, in windows, but not under Netscape 6 in Linux. This is very troubling, but I assume a sign of things to happen to windows. Also, I was hoping to avoid the type of solution Harold suggested. After all, the attractiveness of Java is that the user doesn't need to have any idea about what they are doing, and doesn't have to have any software installed. And, that is why I moved away from file based IO towards sockets only - because the user could avoid the security policy issue. With these changes it only makes it more like traditional software, and more confusing for the user who 'only wants to get the thing working'. Hugh >Harald Albrecht wrote: >Jar up your classes and drop the jar file into >your JRE's extension directory. The extension >directory is usually called 'ext/' and is below >the 'lib/' directory. Make sure that >'lib/security/java.policy' grants all >permissions to all Java extensions lurking in >the extensions directory: > > grant codeBase "file:${java.home}/lib/ext/*" {
> permission java.security.AllPermission;
> };

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc