Garo Garabedyan- a private blog

Mashups, a small applications which communicate between each other, are very powerful. XHTML is so standard and this enables mashups to communicate in a very high level of data integrity. Web is going to be a new Operating system which operates extremely powerful with abstract data.

WWW like an Operating System. SOA in the presentation level
On this post, I have expressed an idea of using JavaScript Script Tag Hack (as Douglas Crockford calls it here: http://javascript.crockford.com/script.html) as a transport pack of data. I have added some additional thoughts about applying SameOrigin Policy to SRC attributes of SCRIPT tags and proving a document space to them which is the only XHTML content they can read/write. (one XHTML content can be read/write by scripts, but this JSs can’t access space beyond their defined).

Now I have worked on this idea, and I upgraded it.

I will explain it by an example:
domain SomeDomain adds to its DOM tree:
<dynamicJavaScript src=”different domain main JS applicaiton file” onError=”SomeDomain JS function to handle the problem“ HTMLspace=”document.App1.Space” jsInterfaceToCommunicate=”SomeDomain JS class which tells serves some wishes loading app needs like accessing general JS functions (alert, confirm and so on), SomeDomain communication between apps on the platform and so on” id=”app1“>

dynamicJavaScript tag can has additional events like: onLoad, onExit

The JS code loaded in document.App1.Space will not be able to access different DOM space, neither reading something different, nor writing somewhere else.
Stopping execution of this kind of JS codes can be able so: app1.stop();

JS code loaded in dynamicJavaScript tag is free to execute XMLHttpRequest-s to its domain. It is free to use its HTML space (which is granted in the dynamicJavaScript tag parameter) as he wants to without any interruption. It is actually an HTML page running like in IFrame, but with the ability to connect with the rest system and this way exchange data, call functions and so through a secure line and when it is expressed it will happen only with the permission of the both sides of JS apps.

If any of this attributes is not set, it is treated as a sign of enabling open access. Behaving like nowadays mashups.

Popular task managers are oriented to remembering tasks according to previously set date and time of reminding.

In real life people are engaged in tasks with not strict scheduled time of start and end. Many time people have to consider with their place in the city right now, about the city traffic in this moment and so on.

Thing are too complicated in order to be done in one moment. Why don’t we use Business Intelligence and SOA?

Imagine a Task Manager which runs on GPRS mobile phone. This software can establish a connection to the business server and retrieve information about the workers which work around the user and understand is there something important which is suitable for him.

Just like Twitter, the user will be free to enter information about his job at the moment before starting doing it and this way to inform all his chiefs, the workflow (Business intelligence) software and co-workers.

Desktop Computers are too old for the business, now people start from the web (which is its own SOA OS). Desktop is useful for many things, but not for business, which is fast.

It is crucial to enable mobile phone applications to react on events. Do you know a general interface between the cell phone OS and every application, by which interface the application can declare interest on some events, and when they occur, the application to be informed. It is not energy efficient to have many applications running at same time and each of them to ask periodically about possible changes (events). Mobile Phone have to use hardware to restrict when something get changed, and when it changes a call to be made to the OS, not only rising a flag.

—-

About the idea expressed in the last paragraph:

We know that mobile phones need to run J2ME in order to execute any java application. Now are modern, not java applets and applications, but widgets, which are placed in desktops as small apps.

Imagine that widgets are written in JavaScript, imagine that you can run such a widget on your cell phone.

How does it happen?

I introduce you Mozilla Prism, which is an application which tries to splits web applications into Desktop applications.

Imagine Mozilla Prism runs on your cell phone (may be on J2ME). It enables you to interact with our web applications like they are part of your phone’s software.

It will be great if Mozilla Prism enables overwriting of some JS DOM events with the aim of communication between the cell phone features, the rest JS widgets and the JavaScript widget. Event-Driven architecture of widgets can be enabled this way.

There are many things that we can say about JS Widgets vs Small Java Apps. Why you think Linux, Mac OS, Windows Vista provide small application execution on your desktop.

Just like the old functional programming languages like LISP

In OOP languages an object is built up by private or public functions and variables in general. In this manner I ask to technically treat at programming language or framework level the function as an object.

Object can be inherited and can inherit (object) and implement (interface). Reference to an object can cause object casting.
Function can’t be inherited and can’t implement, too. Reference to a function can cause object casting

Procedural languages provide local and global variable distinguishes and encapsulation in this manner.

It is a design principle to use objects only when you need them, not always in order to not make an useful class diagram. For the rest of the cases use algorithms written in functions.

Advantage: Can have a link to a function and this way call it. Can cast function and use its past implementation. To force object casting with a reference to a function, not only with a reference to the object.

Making things more SOA, but not distributed.
To not engage only with the object, but also with the function. Apply this to parallel problems where you have to lock some code in order to ensure secure execution.

I think that the presented down way of loading data from different domains is the right way of implementing SOA in the open architectured WWW. Making WWW as powerful as an Operating System.

Introduction on SOA, SameOrigin Policy, Cookies, Authentification practices and Ajax:

Since I have been a big fan of Ajax I was reading many stuff about how XMLHttpRequest is useful and what are its’ weak parts. I was unhappy to read some developers’ opinions about how they find SameOrigin Policy not allowing Ajax apps to be fully SOA and let JS to connect to different domains but only the source one. I think that SameOrigin has its purpose about the user and the policy behind the technology achieves it very well.

I find it useful to attach its’ cookies every time when a request is made to some domain.

Cookies are may be not the right technology to store session information, hidden fields are a better option. But there are some cases when session cookie is needed: user opens a page in many tabs and in this particular case it is not user-friendly to force him to re-enter its authentication data when he opens an URL not containing in itself the session information.

I share the decision of making XMLHttpRequest not able to connect to different domains, only execute and process requests to and from the source domain.

SOA is based on exchanging data between services. Service is a component of an application (possible and very good practice is a service to be used by many applications, which are unknown to the service) accessible trough a network connection (Internet too). It is possible and useful processing data from different sources by JS code executed in a browser.

I think that the next technique of loading data from different domains is the right way of implementing SOA in the open architectured WWW. You should let the other domain to do what he wants before to give you the requested data. The simple bean object (json implementation or whatever) is not a decision when transmit data to unknown apps in the web. Just let the other domain to be able to establish a direct connection with the user in order to ensure some security policies. Or even collecting some user’s information/ wishes and transmit them to the it’s domain in order to be calculated the main data which later to be passed to the first JS application.

Note: JavaScript no matter it’s SRC tag is thought to be part of the source domain of the web page, and SameOrigin Policy doesn’t allow this code to establish XMLHttpRequest to it’s SRC domain. Needed to be used again dynamic JS loading, but this time this loading script’s SRC to be non-guessable from the main JS application in order the letter to not bypass the public JS script and try to load the main data by itself and this way break the policy applied which the first dynamic loaded JS script tries to apply.

Technique allowing general like SOA between JS code executed in a browser and a servers on many and different domains:

I wanted to see an execution of SQL statements on stored data by Zoho Creator From Apps. So this is an example based on Zoho Creator execution of SQL statements through JS Api (this idea is still not implemented but Zoho promised me that they will add this to their feature list).

Request:
RequestURL: “http://zoho.com/app/sql.jsp?” + Session cookie pair (double cookie sending) + “&” + encrypted SQL request
Headers: all the cookies (with the session cookie in this count)
Response:
“zohoParser(” + JSON data + “);” or “[JS code which checks if user wants to allow this page to view the received data]; if ( [user wants and allows] ) { zohoParser(” + JSON data + “) }; “

Scenario:
The client JS generates SQL encrypted request, writes a function called zohoParser which by a known array of parameters is supposed to present the received data to the main application and this way bypass Same-Origin Policy, adds to the body of the page: “<script src=”+ RequestURL +”>”, and waits until the data is received and then zohoParser called by the new loaded script with arguments- JSON data.

Used sources:
JSON security
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html
http://ajaxian.com/archives/gmail-csrf-security-flaw
Same-Origin Policy
http://taossa.com/index.php/2007/02/08/same-origin-policy/

Notes on vulnerabilities:
By rewriting some functions and methods from the JavaScript main libraries can be compromised the behavior of the scripts. Even more when they don’t know each other’s origin.

Future work on JS and browsers:
It is a new idea to program web browsers to treat every JS loaded script from its SRC domain. Providing its own script space in the web page and a way to declare public methods which are able to be accessed by this pattern: [domain].[publicFunction].(data); from the rest JS domains in the particular browser tab.
Main domain JSs can coordinate the execution of the scripts, their talks between each other (function callings between different domains scripts) and the access of the HTML body by locking some HTML roots and JS commands or by overwriting writing functions in order to apply some policy, which by default are parallel and without a restriction to access transmit data between themselves and the HTML body (DOM).
Main domain JSs can create new parallel scripts.
This way we can prevent any ill-intentioned overwriting of functions.

Conclusion:
I hope this technique will enable in one web page to be placed many and different data sources and this way make WWW as powerful as an Operating System.