Garo Garabedyan- a private blog

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.

I haven’t done in my life any Office application. Everything that I have done in this field is just reading and watching how the big players develop big packages of products.

http://googledocs.blogspot.com/2008/02/stop-sharing-spreadsheets-start.html

I think that the next step is to enable users to create their own forms by a spreadsheet tool pallet and every input data to be saved in the spreadsheet, which of course can not be shared. This way design a small form app easily.
It seems a useful stuff for a small business to have this fast communication with its community.

IBM’ s DevEngage and Zoho Creator are applications which first lets you to design the form and then creates the DB, but the letter is too function less, if you let the user to start from its DB, you can enable him to create a powerful form(s) application.