Re: Browser Inter-Tab communication via Applet
Richard Maher wrote:
For some time (ever since a guy called Bojan Nemec told me about it :-) I've
been toying with the idea of my Java Applet declaring its TCP/IP Socket as a
static class-variable instead of an instance-variable, and on each
invocation (new page, new tab, or new browser) the init() would check to see
if the Socket was already connected (and in my case User Authorization
completed) and, if so, skip that bit. Where I think it would be useful is
when there is a Control-Panel/Dashboard requirement, similar to what Arne
and another poster were discussing recently, where each browser "tab" was a
different set of instrumentation/view. All pages being servered by a single,
secure, feature-rich, connection-oriented, context-laden, and
high-performance Socket.
NB: If this is simply *just not doable* then please let me know now before I
spend a few days trying to get it to work :-)
If the applet specs guarantee that multiple pages in different tabs
running the same value will share the same JVM, then it should work.
Andrew Thompson is probably the right guy to tell you if that
is the case.
In general I am not too keen on static stuff, but in your case
it could improve performance.
Some issues that spring to mind (that I hope someone can offer advice on)
are: -
1) To continue my "single reader-thread to oodles of writer-threads" model,
I'm really hoping that JSObject.getWindow() will return something that is
both unique to each web-page instance (wherever it is hosted) and the
accessible from my single reader thread. I plan to store it in a Linked-List
along with a Unique Id that will accompany the user request-messages on
their trips to the server and when they comes back, I'll search the list for
matching index-number, get the corresponding JSObject, and then perform the
.call(). (Perhaps JSObject is serializable? No wait - there's a toString()
method! What's the reverse? I'm guessing you can't simply cast the String as
JSObject.)
I would expect JSObject.getWindow() to return something different
for different pages.
A (Hash)Map sounds better as data structure than LinkedList to me.
Easy to look up by id.
2) I hope that JSObject.getWindow() returns the same thing in the Applet's
destroy() method as it does in the int() method so that I can do a reverse
lookup. Hey, there's a JSObject.equals() method - You bewdy!
I would expect so too.
But check.
The applet world has tricked people before.
3) The whole concept of Socket-Hijacking a la mode de Session-Hijacking, I'm
gonna leave to one side for the moment. I'm relying on Java to prohibit the
manual construction/fudge of a Java Socket on top of just any old socket,
and the operating system to protect a socket in one process/image from
access by another unprivileged process/image.
4) How do I prevent just any old page from including an <object> tag for my
Applet and gaining access to the (possibly pre-authorized) Socket? Off the
top of my head, I could store the Document Base of the first page that
actually passed authentication, and if any subsequent page comes from a
different DB then prompt for username/password again. Any other tools in the
toolbox that I can use to secure access?
Since they can already download your applet, decompile it, make
modifications and recompile it then you really can't prevent them
from doing stuff like that.
So I suggest that you do not waste to much time on that.
5) I'll have to introduce a logout function as that functionality is
currently enforced automatically by any page-change. I guess a dialog box
with some useless Socket statistics and a logout button should suffice.
(When the number of JSObjects is reduced to zero, an automatic logout will
take place.)
6) JRE instances. Funny how IE and FF don't share the same JRE instance :-)
Even with Java 6 and up, as long as the Applets ask for the same Java
version then can there be every expectation that they'll share the same JRE
instance?
If the JVM were running in a separate process, then it would be
possible.
But if it is embedded with the browser process, then it can not be done.
Arne