Ken Hardy wrote:
>
> >Probably not just a Squid issue, but here goes.
>
> No, it's not a Squid issue at all. Squid proxies some specific
> protocols; it doesn't and cannot proxy any arbitrary protocol that
> someone may program into a Java applet, even if the applet had any
> support of a proxy.
>
> >Tried to try out some new java-base Chat site:
> >
> ><URL:http://www.powersite.com/uplink/index.html>
> >
> >The java involves network calls, and even though my Netscape browser is
> >configured to work via a proxy server (squid of course!), Netscape goes
> >off and tries to connect to the java server directly - where it gets
> >jumped on by our firewall.
>
> You're probably SOL. The Java security model only lets an applet
> connect back to the system from which the applet was downloaded, with
> no concept of proxy. The last I tried NetScape (2.x?) it would not
Except that most of the Java implementations out there (the copy of
netscape that I'm using, for example) allow an applet to send data out
to a host of the same name (which shouldn't be permitted) instead of to
the same numeric address. Also, there are ways of getting the java
interpreter to send data to just about anywhere in netscape and MSIE
(most current versions). A demo we got recently showed an applet that
continued to deliver the user's keystrokes to a remote host that the
user had requested nothing from, and continued to do so after the
browser had terminated. Multi-threading is a wonderful thing. :/
Apparently not too many implementations really cared all that much about
the security model. That looks like it's going to change.
D
Received on Tue Oct 29 1996 - 12:22:22 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:24 MST