Operating System - OpenVMS
1748209 Members
2711 Online
108759 Solutions
New Discussion юеВ

Re: Browser Inter-Tab communication via Java Applet

 
SOLVED
Go to solution
Richard J Maher
Trusted Contributor

Browser Inter-Tab communication via Java Applet

Hi Bojan,

Great to see you're still around!

It'll take me a bit longer to digest your answer to my other questions before I reply, but the funny thing is I mentioned your name just today over in comp.lang.java.programmer and I'd be interested in any feed back you may have on the feasibility of the strategy below.

(I'm also really interested in the best LinkedBlockingQueue type of class to manage the list of JSObject.getWindow() objects, but more on that later.)

Cheers Richard Maher

The following is from: -
http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/06e807a645ea8e78#

Hi,

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 :-)

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.)

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!

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 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?

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?

7) Anything else?

Cheers Richard Maher

PS. Which Frame does the JSObject.call() activate in (let's say there is a function with the same name in each frame of a 3-frame frameset? Current? Top? Different JSObject.getWindow() result for each frame?
3 REPLIES 3
Bojan Nemec
Honored Contributor
Solution

Re: Browser Inter-Tab communication via Java Applet

Richard,

1) There is a wide used method for JavaScript serialization/deserialization it is named JSON (JavaScript Object Notation). There is the link:

http://www.json.org/
http://www.json.org/js.html

The second is for JavaScript.
Or just google to find more.
The JavaScript object is serialized in a string. So you can serialize in one window (one JSObject) and deserialize in another window. And more, you can serialize/deserialize betwen two different systems.
2) You give the ansawer. It should return the same object every time you call it (in the same window).
3)
4) I will first test if the browser create two different Applets if they are loaded from different Document bases. You should look to the static components of the applet.
5) Without this you get in troubles. You should also stop the reader thread.
6) You mean the same Virtual Machine (running process) or the same software distribution?

Bojan
Richard J Maher
Trusted Contributor

Re: Browser Inter-Tab communication via Java Applet


Hi Bojan,

1) I was aware of JSON; at least in so far as the Yahoo! APIs, their "callbacks", and eval()ing JSON. I wasn't aware of the stringify() and parse() functions, but I'm not keen on lugging around 17KB of JavaScript just to do that. But I guess we should be discussing the Java side and whether JSObject "implements serializable" and how to get the output into a string instead of a file/socket and. . . and it all gets too hard. Anyway, with your lovely LinkedList/Queue for messages *sent*, I can just check the sequenceNum of the MessageObject at the head of the queue against the incoming message. If there's a mismatch I can log everything out. Otherwise, when the JavaScript Callback calls "done", I'll pop the JSObject off the queue, return, and let it get re-used or GC'ed. I like it!

2) Good news!

3/4) Phew - you had me worried there! My observations are that: -

i) The same Applet (and same codebase) referenced from Document Bases where the server portion is different will yield "different Applets".

ii) Different html pages on the same server referencing the same Applet (and same codebase) still yeilds the same Applet class and an overlay of the static class variables.

I will ask about suggestions for the best OO implementation later, but for the sake of background one of the requirements is this: - One FF browser instance with 4 tabs. The first 3 tabs will be part of the same Tier3Application (eg: PowerStation) the last tab will be a separate application (eg: TimeSheet). When the first of either of the PowerStation tabs is opened, my Applet will create the Socket, connect to the Server, and prompt for Username/Password. The next two pages will see (via the approriate static class variables) that the connection's up and not need to reauthorize. The 4th tab will have the same Applet but the different APP_NAME, PORT, and/or CodeBase, will be forced to a separate network connection and the Username/Password exchange.

Now, in order to prevent a malicious page from just including a an tag for my Applet (let's say in tab 5) and getting a free run at the Socket, I suggest doing this: -

a) The first Applet invocation for a given application (the one that will physically request authorization from the user) will store the results from Applet.getDocumentBase() along with the other Application-Specific data (Username, Connection-Time, Socket, etc)

b) Each subsequent Applet invocation (appears to require same browser instance here) will check APPN_NAME, PORT_NUM, CHARSET, CODEBASE, SSL_REQD, BUFF_SIZE for equality. If there's a mismatch with any of that then a new Application will be created and the user has to logon again.

c) Even if everything above matched, this final check is performed to prevent a valid page being included in a subserviant [i]Frame. If the window.top.location.href (good resons for not using Applet.getDocBase() here) does not have the same hostname as the originally saved Document Base, then a new application/login is created.

Look, I'm undoubtedly becoming tedious, and over-sharing, so I'll stop. But If you think the above is not solid please let me know why. Maybe the final check "c" is redundant and performed by the sandbox anyway?

I'll just test it.

5) Ok. Thanks.

6) Yes I mean JVM/Process. My experience (FF with Server URLs at least) is that multi-tabs are fine with class variables but multiple browser instances get separate JVMs.

Cheers Richard Maher
Bojan Nemec
Honored Contributor

Re: Browser Inter-Tab communication via Java Applet

1) I think that it will be very dificult (or inposible) to do the serialisation on the Java side. Probably you have to write something like JSON in Java. If you look at the source of the JSObject (see links in http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1323184 ) Java knows nothing about the JavaScript object it knows only its internal number. Why not use JSON? Your Java code for serializing/deserializing will also eat some KB. And an image on your web page will eat much more. JavaScript is cached on the browser side so the download will be only once a time. On the other hand You probably can not simply transfer the JSObject from one window to another (or maybe you can? To be tested).

4)

i) That is OK.

ii) Still OK.

If the two applications have the same Applet & codebase you should have more than one working thread. The insertMessage method should find out with which thread it have to talk (this can be done only once in every window and then the thread is remebered in a local variable for reusing).

Abbout malicious code recheck many times. A quick look seems OK but better recheck.

6) To me this is perfectly logical. The Java virtual machine is a "simple" program in this case subprogram (see JNI). Multiple browser instances with the same JVM will bring much more complexity in the browser logic. Creating a separate process, inter process communication and much more. Think only to the JSObject. The internal and/or long_internal is probably just an address or index in a table of JavaScript objects which stays in the memory of the browser program. How to transfer all the stuf behind this to another process?

Bojan