Re: [xmlblaster] applet security problem

[Marcel Ruff <mr at marcelruff.info>]

Madere, Colin wrote:

> Well, we're trying to avoid having to make users change browser policies so
> that's not really an option.  Why does xmlBlaster need any system properties
> or is this just a side-affect of using the "jutils" library?

Hi,

i don't think that jutils is the only place.
Using the new xmlBlaster java client library with applets
is not at all tested.

I think this needs some days experimenting with applets and adapting code
to get this running without any security problems (avoid
file access, System access etc.).

If you want to go this way your code changes could be
patched into xmlBlaster so you won't loose te changes
in future releases and others could benefit from it as well.

Another important point with applets is to limit the jar files
needed to minimize download time.
This will be quite an effort as well.

For applets the SOCKET protocol is probably the right approach:
o Supports callbacks through the same connection.
o Only some small classes to download.

I could imagine a very small java client layer
using the SOCKET protocol drivers directly without
XmlBlasterAccess (overhead/features).

With CORBA, XML-RPC or RMI the client has an own
callback server which forces you to open the firewall for this
port back to the browser.

Eyery of the Applet solutions needs some investigation
and coding ...

Another way could be to sign the applet to reduce
security exceptions.

Finally you can implement a very pure own socket which
talks with a servlet which is the proxy client to xmlBlaster
or you reuse the persistent http browser plugin servlet
framework: your applet
behaves like a browser with an http request. This
way you have no firewall or proxy problems at all.

regards,

Marcel