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
- "XMLHttpRequest object can retrieve and submit XML data directly, all in the background without refreshing the page. With this object you can convert retrieved XML data into HTML content using JavaScript, rely on the client-side Document Object Model (DOM) to read the XML document node tree and compose HTML elements that the user sees."
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");"
- set header content type, else IE client fails
"get rid of warning on Cross site scripting - MS sites"
"Mac users of
FireFox and Safari need code change in checkName function'
- test sb "if(response == 1)" where the number should not have quotes around it
"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
CategoryWebBrowser