Ajax Client Engine Discussion

AjaxClientEngineDiscussion concerns itself mainly with opportunities, problems and solutions related to the use of XmlHttpRequest object as the Ajax client engine. I understand there are other similar but lesser used alternatives (e.g., MacromediaFlash) which will be left out.

From the web somewhere
Anchor article - "Very Dynamic Web Interfaces" at http://www.xml.com/lpt/a/2005/02/09/xml-http-request.html

The above was referenced by the ground-breaking Jesse James Garrett article listed in the parent AjaxWebApplications page. It appeared to be an article that generated lots of discussion at XML.com. Further references were made there about various considerations, some are listed here in sections below for further exploration.

Errors, Omissions and Improvements to the anchor article

Remarks below all sourced from various comments to the base article

"res.setContentType("text/xml");" "get rid of warning on Cross site scripting - MS sites" "Mac users of FireFox and Safari need code change in checkName function' "Need www in URL"
InternetExplorer Ajax without ActivexTechnology

Further reference article at http://weblogs.asp.net/mschwarz/archive/2005/08/24/423495.aspx

See also how PhpLanguage, using inner HTML and dynamically added "script tag", to get AJAX without ActiveX. See note in main AjaxWebApplications page.

Why use XML

JavaScriptObjectNotation mentioned as an alternative in a discussion thread to the anchor article.

One person suggested reusability in clients without JavaScript as reasons to using the bloated XmlLanguage. But JSON is available in lots of languages.

Thread safety considerations

One person remarked on the concurrency problem of the simple example in the anchor article. He suggests read up on "JS closure methodology" at http://jibbering.com/faq/faq_notes/closures.html. Others had problem with getting data out using the "inner function" approach.

DOM3 standards supported widely (outside of MSIE)

The commentator said something like "And if that is used, then coding to support browsers (including MSIE fork) is simplified."

WebApplicationSecurity considerations

A respondent to the anchor article suggested WebServicesSecurity is required on top of what is presented. He was using XmlHttpRequest to process SoapProtocol messages, and complained that only Office03 MSXML parser kit has some desired security features, and that may not stay available in a future version.

Would use of AjaxWebApplications expose application logic to a much wider audience that would otherwise be protected on the servers? If so, would that have assisted people with intentions to deceive through SocialEngineering measures?

To the first question: Not necessarily. AJAX is about improving the user experience of applications that would otherwise be implemented mainly using raw HTML on the client side, with minimal or no Javascript and certainly no use of XMLHttpRequest. The underlying server-side functionality, including security considerations, should be essentially the same. Therefore, I am not clear how client-side implementation issues would necessarily expose application logic to a wider audience, any more so than server-side logic would be exposed to a wider audience on any given non-AJAX Web application. Perhaps I've misunderstood the question?

To the second question: Successful SocialEngineering will obtain (for example) the same system user IDs and passwords whether AJAX is used or not. AJAX is irrelevant in this case. However, again I suspect I may have misunderstood the question.

See also WebApplicationProblemDomain, AjaxWebApplications

View edit of March 25, 2006 or FindPage with title or text search