| Java menu knowledge base
Firewall FAQ
Are firewalls fatal to applets?
Depending on what they have been configured to keep out,
firewalls may have different effects on applets. In general,
the phenomena reported on this page seem to be rare. Whether
you take the measures listed here should depend on who you
expect your site audience to be and whether they will be
accessing the server across known uncooperative firewalls.
What kind of things can firewalls do to applets?
In theory anything. In practice, so far as problems arise
at all, they arise with Netscape browsers being unable to
get applets to access additional external resources. These
resources fall into 2 categories: (i) image files, (ii) text
files used for (e.g.) menu content.
I've got an isolated case - what should I tell the site visitor?
If you have an isolated report, you may prefer not to change
your website (see below). In such a case you can offer the
site visitor in question a client-side solution as follows:
in the Netscape file "prefs.js" (in the personal configuration
sub-directory of the /netscape/users/ directory, add the following:
user_pref("security.lower_java_network_security_by_trusting_proxies",
true);. (You can remove it again later if you wish). You can edit the
"prefs.js" file with a simple text editor - it's just a text file.
What can I do if a firewall is blocking images?
With imint.com applets you don't generally need to do anything.
We have programmed as many of our applets as possible to
compensate for missing icons and other images - for example,
by supplying acceptable default internal images. If a firewall
happens to block an image, the applet will look different, but
still work. For obvious reasons, the applets this work-around
can't work with are image map applets, which will redirect
to your non-java menu if the image fails to load.
What can I do if a firewall is blocking the external index file?
Use parameter indices instead.
If you are creating indices dynamically, you can dynamically generate
parameter indices as well - just differently.
Who has the right to control how my website looks? Me outside the firewall,
or them inside the firewall?
As web technology becomes increasingly sophisticated, all such software
contains a growing and dazzling array of user-configuration options.
These options can interfere with the way your webpages appear and way
your technology works. Just as users could control their own fonts
and switch off java in the early days, so now they can decide what
functions to allow to java, what type of files may be accessed, how
and where new pages are loaded, etc. The list of configuration options
of this type has already grown to the point where no programmer or
web designer can possibly cope with the configuration of every site
visitor.
The problem is not limited to browser configuration. Firewalls
have moved the same way. While firewalls were originally conceived
to protect companies against outside aggression, increasingly
firewalls are configured to prevent the company's own employees
from doing anything which company policy disapproves of. Depending
on the latest scare in the press, this may extend to stripping every
email of its attachments, or preventing any files of a non-html or non-ascii
format from being looked at. Sometimes the problems are more
subtle.
The responsibility for ensuring that java works in such an environment
is the responsibility of the person who owns and/or runs the browser
or firewall in question. No programmer or web-designer can be expected
to programme around impossible or aggressive systems. In fact, if we did
find a way of penetrating a barrier designed to keep (e.g.) all java out,
we could be rightly accused of "hacking" into secure environments. To put
it another way, it is the right of end-viewers and their employers to
decide what they see of the web and how they see it. Web-designers and
programmers would be invading their freedom by forcing particular segments
of code on them.
So what is the final line of defence against a super-aggressive firewall?
One unique feature you will find with imint.com is the escape page.
This enables our applets, so far as they can, to detect partially disabled
java functionality that might prevent the applet from running properly. The
result is to load an alternative non-java page. The result is that your
website continues to look professional. There is further help on this topic
in this support area.
|
|
