Today everyone talks about Web 2.0. But while the idea of a collective intelligence, implied here by the term’s inventor Tim O’Reily remains an object of trivial speculations, it is obvious that the World Wide Web is changing. Web applications are increasingly approaching the level of functionality, which is usually found only in desktop applications. And as this trend is gaining momentum, we can already witness the dawn of a new era brought about by a novel kind of web applications - Rich Internet Applications (IRA). At the same time, the popularity of terms like Web 2.0 and RIA makes developers use them as an attractive label on their products, without actually understanding the meaning behind those notions. So what does RIA mean, eventually?

The term Rich Internet Applications (RIA) was first mentioned in Macromedia’s promotional materials in March 2002. By this the company’s managers wanted to point out that the well-known Flash technology is not limited to creating attractive visual web-elements, but can also be used to develop fully functional web-based business applications. Apart from providing user with data, static pages of older-type sites are much less flexible in terms of user-data interaction compared to desktop applications. Every time you request additional data (navigate the site) or upload data to server the pages have to reload. This is often inconvenient and, above all, can compromise security because of the possibility of data loss (say, due to a lost server connection). Yet this is exactly the way Web 1.0 works. Every time you type URL or save data in a web form, server receives instructions which it then uses to form a page you see next. With RIA, there’s no need to reload pages. As you click to receive additional data or send data to server, the latter receives corresponding instructions and uploads the results onto the page. The application receives server’s response and changes accordingly. For example, if you browse an internet catalogue of an older type, every time you hit the button “next 20 items” you will have to wait for the page to reload and for a new page to shape. With a RIA-based site, you can request items 50 to 80 or all items in a specified price range on the same page, and with every new query only the list of items will be updated.

Today RIA can be developed with the help of AJAX, Adobe Flex, Windows Presentation Foundation, Flash, Java-applets, Java and some declarative languages - such as XUL and MXML. Of all these tools only AJAX and Flash gained wide popularity - mainly because they are easily available. And whereas development of Flash-based applications is quite a resource-consuming and expensive process, developing RIA with AJAX takes hardly more time then it would with an older-type, classical web-site. In most current projects Flash is only used when it is needed.

The very name - AJAX (Asynchronous JavaScript and XML) - reveals the essence of the technology. It allows the client engine and the server-based part of the web-application interact asynchronously. This means that your browser can request server at any point (say, when you hover your mouse over a link) and, vice versa, server can upload data to browser at any time, without waiting for a new page to be requested. How does it actually work?

One of the most popular uses that AJAX has found is in the web-based drag & drop technology. You must have already seen the virtual desktop services - such as found at www.netvibes.com and www.pageflakes.com. Their users can arrange widgets (useful data from other servers) on the screen and adjust their size just like we usually do it in Microsoft Windows. These features are now increasingly found in business-applications. For example, at www.atlas.cz users can customize the starting page with as much ease as any virtual desktop.

The possibility to customize pages with the help of ready-made design templates reduced the dependence of CMS (Content Management Systems) users on site developers. Using the mouse a CMS administrator can arrange various data modules, specify their size, color and other attributes at a page. Then s/he can save the current configuration which will later be displayed to site users. Yet advantages provided by Drag&Drop technology to CMS administrators are even greater when it comes to site content management. In latest CMSs all the administrator has to do to change position of any document in the structure (or of an entry in the list) is to drag and drop it at the desirable point. It is exactly the way files are managed in Microsoft Window Explorer.

As we’ve already mentioned, with RIA there’s no need to upload all the user data at once. Parts of it can be uploaded later, when they are actually requested for. For example, when administrator switches to the CMS’s site structure management interface, only the basic level of the hierarchy tree is loaded. If later user wants to explore any of the tree’s “branches”, the additional data will be uploaded instantly. This feature is even more important in managing various lists. The application returns to the interface only those entries that user specifically requested. Moreover, even data input procedures acquire new features. Modern web-applications increasingly offer input option which acquired wide popularity thanks to Google Suggest service. As soon as you start to type something in the required field, a dropdown list appears with suggestions based on the already typed in elements. Those who at least once had to, say, choose a producer from a seemingly endless dropdown list in the SELECT field will fully appreciate the convenience of this feature.

The fact that there’s no need to reload the page every time its user performs an operation changes the very perception of a web-interface. You can type in data in several forms placed on one and the same page but, say, on different tabs. Then all the data can be saved simultaneously. And, importantly, in case due to some reason (a lost connection, an internal error etc) the data is not saved, the interface will report it and let you try again. And we all know only too well that poor security was one of the basic flaws with older-type web interfaces.

It is obvious that apart from everything else IRA-based sites can report the status of processes and their results. Today it is only perceived as natural when any element involved in some system operations displays their status on a special bar. Let’s say, for example, that you requested a list of specified items to be displayed by an e-catalogue. In that case you have the right to know what the system is up to from the moment of query to the moment the list is displayed. If due to some reason the server is unable to return the requested data, you should receive the corresponding message.

With RIA the functionality and security of CMSs reach a totally new level, which earlier was available only with desktop applications. Yet we should not forget that RIA-based interfaces are capable of interacting not only with their own server software, but with third-party applications as well. This fact lets us hope that present-day CMSs will gradually evolve towards ECM (Enterprise Content Management), thus bridging the gap between corporate sites and corporate network information resources.

Posted by MixedSoup | No Comments »

AJAX ? AHAH ! sounds funny, but AHAH now stands for Asychronous HTML and HTTP, a technique for dynamically updating web pages using JavaScript, involving usage of XMLHTTPRequest to retrieve (X)HTML fragments which are then inserted directly into the web page, whence they can be styled using CSS. Nothing new until now, except that inspite of retreiving XML, AHAH stands for retreiving (X)HTML.

AHAH is intended to be a much simpler way to do web development than AJAX : “Asynchronous JavaScript and XML.” Strictly speaking, AHAH can be considered a subset of AJAX, since (X)HTML is just a special kind of XML.

The main reasons that made AHAH exists :

• The lack of custom XML schemas dramatically reduces design time
• AHAH can trivially reuse existing HTML pages, avoiding the need for a custom web service
• All data transport is done via browser-friendly HTML, easing debugging and testing
• The HTML is designed to be directly embedded in the page’s DOM, eliminating the need for parsing
• As HTML, designers can format it using CSS, rather than programmers having to do XSLT transforms
• Processing is all done on the server, so the client-side programming is essentiall nil (moving opaque bits)

This is a sample code for sending an AHAH request:

function ahah(url,target) {
// native XMLHttpRequest object
document.getElementById(target).innerHTML = 'sending...';
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
req.onreadystatechange = function() {ahahDone(target);};
req.open("GET", url, true);
req.send(null);
// IE/Windows ActiveX version
} else if (window.ActiveXObject) {
req = new ActiveXObject("Microsoft.XMLHTTP");
if (req) {
req.onreadystatechange = function() {ahahDone(target);};
req.open("GET", url, true);
req.send();
}
}
}

Then to receive an AHAH request

function ahahDone(target) {
// only if req is "loaded"
if (req.readyState == 4) {
// only if "OK"
if (req.status == 200) {
results = req.responseText;
document.getElementById(target).innerHTML = results;
} else {
document.getElementById(target).innerHTML="ahah error:n" +
req.statusText;
}
}
}

AHAH, also called JAH, for Just Asynchronous HTML, was introduced on May 12, 2005 by Kevin Marks. The term “AHAH” was proposed by Ernest Prabhakar during the 2005 Web 2.0 conference, and later adopted as part of the REST-Enabled XHTML microformat for web services. AHAH, now I understand better, did you ?

Posted by MixedSoup | No Comments »

We have already laid out some of the loopholes that could be used by different hackers. In this article we will take a look at a very basic hack that could be done even by none-developers and how to prevent it.

Personally, the biggest problem for any Ajax based developer is the transparency of the source code. To understand this let us take a look at different online applications that runs in a different language. An HTML application for example will only show you a source code with the input box and nothing else. That information is useless for hackers since it just translates a very small part of what they see. An HTML based application securely covers its source code and shows practically nothing. A hacker will probably use a sniffer (network traffic analyzer) but it will just show up some information on what server is used. In that point, a hacker may already create a hacking script but hackers will still have a long way to go through just to infiltrate an HTML-based website.

Unfortunately for Ajax, that is not the case. Ajax based applications have to “show” their source code to the client to ensure the program goes through. It is as simple as installing the right Firefox add-on tool that shows the actual code of the website to know the actual source code. Some even say that a website is not secure enough even the FrontPage application could show the source code. With that, hackers will practically know everything about your website and its process. If they have a sniffer, they can immediately build a small script to hack your website.

There are three recommendations I could give to somehow prevent others from seeing the actual source code:

1. Obfuscate JavaScript – quite an advanced word but it just actually tells the developed to confuse the hacker by getting them confused on what you are writing. There are tools that you can use that enable you to build a confusing website. But this will only confuse the hacker not the system. This will probably discourage the hacker but if the attacker sees the formula, you are back to square one in security.

2. Disable Right-Click Function – Remember those pesky messages that you see in a simple website where they do not allow copying? That will probably work on your website but not for long. Again, you are just buying some time for any hacker to think of alternatives to access your site. But this is good especially protecting yourself from newbie hackers.

3. Code Compression – There are web development companies that sell tools for code compression. To put it simply, the code is scrambled so that it will never be understood by any tool by hackers. Since this is a very complicated security tool, be sure to prepare a little bit of funding since these code compression tools will cost you.

Remember, the first two tips are just simple tricks to buy you time. Be sure to use this when you are just looking for a proper compression tool for your code.

Posted by MixedSoup | No Comments »

On the surface, Ajax is the acronym for Asynchronous Javascript and XML. However, the acronym doesn’t describe an object, but a technique for web development. The definition incorporates a suite of technologies working in conjunction for web development. These techniques help produce more responsive and interactive web applications. Increased interactivity is required by web applications since so much of the marketplace and the services they require are currently electronic (the “e-market”) and conducted through the Internet.
Web applications allow applications to be accessed through web browsers rather than requiring software to be installed on individual computers. Webapps, as they are commonly referred to, are used to install and run many of the web-based activities that are now part of everyday life. For example, webapps are used to run Webmail, which includes all major e-communication applications that operate through a web browser, like Yahoo!Mail, Hotmail, and Gmail.
Webapps also help run on-line retail sales, auction sites, wikis, and Webblogs. They are essential to the many uses of the Internet we currently take for granted. The webapps supported by Ajax increase speed, interactivity and usability. By allowing web pages to exchange small bits of information with the server without the user’s knowledge, Ajax helps web applications seem more responsive and user-friendly. The entire page doesn’t need to be re-loaded every time a request is made. The ‘refresh’ function takes place behind the scenes.
This article will provide a general discussion of Ajax, its components and uses.

Background

The term Ajax was coined in 2005 by Jesse James Garret to describe a suite of technologies and approach he was presenting to a client. However, the impetus behind the development of Ajax was remote scripting initiated in 1995 by Microsoft. Remote scripting made it possible for interpreted programming languages to carry out functions through another program rather than by a computer processor that hardwired processing instructions.
Remote scripting allows scripts running inside a browser to communicate with and exchange information with a server. Microsoft’s Remote Scripting (MSRS, 1998) allowed for asynchronous loading of specified content without requiring full web page reload, similar to Ajax. Java applets allowed clients to communicate through Javascript, thereby facilitating asynchronous loading through a common language. This developed into Microsoft’s XMLHttpRequest which was introduced in 2000 on Microsoft’s Internet Explorer 5.
Online collaboration in the web development community through newsgroups and blogs, helped XMLHttpRequest replace Java applets for asynchronous web content loading. XMLHttpRequest is an API (application programming interface) that Javascript and certain web browser scripting languages use to move data between web servers (server-side) and users (client-side) using “http” (hypertext transfer protocol). This made communication easier, more standardized and, therefore, more translatable. It is one of the primary components of Ajax technology. However, there is much more technological collaboration that makes Ajax possible.

Components

The technological components that collaborate to make up Ajax technique are various. But, they all work together to increase web page user-friendly accessibility. XHTML is a markup language that provides a more rigid syntax than HTML. It is an intersection of HTML and XML. This provides a broader impact by using the standard XML library to communicate document content. Ajax also requires JavaScript or other client-side scripting language. Client-side scripting languages allow web pages to tailor their content according to user specifications. As previously mentioned, XMLHttpRequest allows asynchronous data exchange with the web server. XML provides a standardized format for client-server transfer of data.

Points of Interest

The primary reason for the development of Ajax was to by-pass existing page-loading requirements through HTML/HTTP-defined web pages. Ajax redefines user web-page interfaces as dynamic, intelligent and based on data. Web pages usually require the heavy operation of reloading the entire page each time a user needs a different dataset to request a different function. Ajax intuitively requests and uses data, through XMLHttpRequest, to make loosely coupled web pages act like tightly coupled applications.
The only interference is the lag time required for the communication to pass though the web browser and this happens almost instantaneously. This allows for a more intelligent recruitment of data based on user specifications. Perhaps the most popular applications of Ajax are observed in Google applications like Google Maps, Google Suggest, and Gmail.

Posted by MixedSoup | No Comments »

We are always emphasizing on securing our websites especially when they are Ajax based. There are so many blogs that were written reminding developers the weakness of Ajax because of its complexity. We’ve also written ourselves some tips to ensure the program you just created is as user friendly as it is secure.

But as time goes by, newer hacks are invented so new security measures have to be done. Here are the updated tips that any developer should observe if they are interested in created and maintaining the security of their Ajax based website.

1. Tightening the screws in your code – when you create a program, you don’t just build a program and create codes that coincide with security measures. Apparently, hackers and even security experts already know this and they have come up with another workaround to access the vulnerable Ajax. Be sure not to leave any leaks at all. As what they say, prevention is better than cure.

2. When developing software, use the prototype approach – RAD (Rapid Application Development) and Agile Development Framework are two of the development models that always rely on creating prototypes. As much as possible, use these models so that each part of the program will be thoroughly checked not only in function but also in security.

3. Sandboxing – This term applies to the security measure that is observed in different programs. Before a new application, code or content will be admitted in the program, sandbox will test it in their system first to ensure the code or the information is safe. This is really challenging in an Ajax based code but it’s all worth it as most Ajax based program are used in Web 2.0 sites.

4. Investing in code review tools – the money spent in ensuring the program is secured is better than money spent on recuperating the loss you have because of the lack of internet security. There are two types of code review tools: architecture and code review. Architecture looks at the program in general while code review takes a look each tool to see if there are bugs. Bugs are actually not hacks so code review will not suffice as it could only take care of at least half of the security problems.

5. Hack the program yourself – of course you already know how it works inside and out, create a simulation where you’ll be place the program under attack. Don’t just do this yourself but do it with your fellow developers as well. Although you might have already done this, give it a little boost by documenting every move you make. It is through this documentation that you can actually run a diagnostic test in case something bad happens.

6. Get outside help – if you’re familiar with the program, chances are it’s going to be very easy. Get someone from the outside to hack the program for you. Remember, document all the programmer’s movements and the program’s responses to ensure you have future reference in case an attack happens.

Posted by MixedSoup | No Comments »

Ajax programming is one of the most exciting new technologies in recent history. Ajax (Asynchronous Javascript and XML) allows a web page to refresh a small portion of its data from a web server, rather than being forced to reload and redraw the entire page as in traditional web programming. Since they can make frequent, small updates, web applications written with Ajax programming can present user interfaces that are more like desktop applications, which are more natural and intuitive interfaces for most users. However, just like Uncle Ben said to Peter Parker (aka Spider-Man™)(1), with great power comes great responsibility. Web applications have become prime targets for malicious users and hackers performing SQL injection and similar attacks.

The flexibility and creativity that Ajax programming affords the developer also places a corresponding burden on him to ensure that his code is secure against these new threats. Also, since delivering a secure application is part of delivering a quality application, the burden is probably felt even greater by the Quality Assurance (QA) team. The QA team will now need to develop an entirely new set of functional, performance and security testing methods in order to thoroughly test the quality of applications using Ajax programming against SQL injection attacks and other security concerns.

It’s in the Code

As an example, consider a hypothetical gourmet food e-commerce web site. This site displays a map of the world to the user, and as the user navigates the mouse pointer over each country, the page uses Ajax programming to connect back to the web server and retrieve a list of goods originating in that country. The following C# code snippet shows the web method in which the database is queried:

[System.Web.Services.WebMethod]
public System.Collections.IEnumerable GetProducts(string country)
{
// update the select command to use the country parameter
this.SqlDataSource1.SelectCommand = “SELECT * FROM [Product] WHERE Country = ‘” + country + “‘”;
// query the database and return the results
return this.SqlDataSource1.Select(DataSourceSelectArguments.Empty);
}

Some readers may notice a glaring security hole in this code. The database query is being constructed on the fly with un-validated user input being sent directly to the database. This insecure programming technique creates a vulnerability to SQL injection attacks, which are potentially devastating to the web application and its users. SQL injection vulnerabilities allow attackers to execute their own SQL queries and commands against the database, rather than those that the developers of the web site intended. The entire database, including customer names, addresses, and credit card numbers, could be downloaded by such a command. The prices of the products could be modified. The entire database itself could be permanently deleted. Clearly, this is a very serious issue. If the developer fails to notice the problem, the next line of defense is the QA team.

The average developer will probably do a quick, cursory test of the application before passing it to the QA department, without checking thoroughly for SQL injection vulnerabilities or other important problems. Instead, he will mouse over a few countries on the map, check that the displayed results match those in the database, and then pass the code off. The average QA engineer typically will be much more thorough. He will mouse over every country on the map and check that the results match. He might even set up an automated test script that will mouse over every single pixel on the screen, and he will check to see if there are any errors in the Ajax programming or underlying page code. But, even this extreme level of thoroughness won’t be enough to find the SQL injection vulnerability. By using a web browser (or automated script recorded from a web browser) as his test tool, the tester has limited his potential requests to only those which the browser can send, and the browser is itself limited by the source code of the web page. In the example above, the browser would be limited to sending only valid country parameters to the GetProducts method, since only valid countries are present in the page code. In other words, no matter where the user (or QA engineer) navigates with the mouse, the only parameters that would be sent are “GBR”, “FRA”, “USA”, etc. Using only these valid, well-formed parameters will never reveal the SQL injection vulnerability. To do that, the QA team needs to expand their arsenal of test tools beyond browsers alone.

Since browsers are so limited, hackers generally don’t use them to break into web applications or execute their SQL injection attacks and other hacks. They use tools that operate at a much lower level, tools that are capable of sending raw HTTP requests to an address and displaying the raw HTTP response. Netcat is a popular tool for this purpose, as is telnet, which has the benefit of being installed by default with virtually every modern operating system. So, instead of opening a browser, navigating to a page, and viewing the rendered HTML response, the hacker types:

nc 172.16.60.250 80 GET / HTTP/1.0

and then receives the response:

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 10 May 2006 18:04:56 GMT …

While interacting with Ajax programming may not seem like it would generate a round-trip request to the server since it doesn’t refresh the entire page, under the covers it’s doing exactly that. Like programming in standard hyperlink navigation or form submission, Ajax programming actions always have an HTTP request and response. So, armed with his low-level HTTP requestor tool, the hacker is now free to make attacks on the application that could never be possible with a browser alone. Instead of sending “GBR” or “FRA”, he could send “XXX”, or “!@#$%”, or “x’ OR ‘1′ = ‘1″, which in this case would successfully exploit the SQL injection vulnerability.

Thinking like a Hacker

In order to successfully defend against the hacker using SQL injection or some other attack, the QA engineer has to think like the hacker. Since the hacker doesn’t restrict himself to using just a browser to attack a web application (with or without Ajax programming), neither should the QA engineer use just a browser to test it. At a minimum, the application should be tested with the same type of raw HTTP tool that the hacker uses. An even better approach is to use an automated security analysis tool that performs these tests. Automated tools can make thousands of test requests in an hour; work that would take a QA engineer a week or more to perform manually. Additionally, these tools generally have an extensive set of techniques that they use to detect security defects such as SQL injection vulnerabilities QA engineers would unlikely be aware of these techniques unless they had a background in information security. There are several excellent security analysis tools available commercially.

Additional resources for learning about web application security and security analysis tools include the Web Application Security Consortium (WASC) (www.webappsec.org), the Open Web Application Security Project (OWASP)(www.owasp.org), and the SANS (SysAdmin, Audit, Network, Security) Institute (www.sans.org).
It seems likely that Web applications using Ajax programming are the future of web development. The robust user interface that web pages comprised of Ajax programming can provide represents a huge leap in usability over traditional web pages. But, this power comes with a price: the programmers and QA engineers must move beyond browsers alone when testing the application. Security vulnerabilities can lurk in code that is accessible only by specialized low-level request tools. Hackers will be more than willing to use these tools against your web applications, so your QA team must use the same tactics to find the vulnerabilities first.

Posted by MixedSoup | No Comments »

In order to protect websites, it is essential to know how it is going to be attacked. One such awareness is to know how to cure cross-site request forgery problem. Though website security may appear hyped, the type of attack that could be made possible justifies the security concerns.

Today let us take a look at a very simple yet effective method to prevent attack in most Ajax based websites and applications:

Cross-Site Request Forgery

When the website starts trusting the user, it is practically the end of the website’s security.
Cross-Site Request Forgery works by accessing your account through your cookie. All the hacker has to do is to embed a picture with a code so that the website will allow the hacker to perform specific actions.

There is actually a basic protection in Ajax that will prevent others from using the above hack. JavaScript by behavior does not allow any image file to be used that easy. However, most of the Ajax based websites rely on user generated content. Because of this function, developers have no choice but to execute authentication.

When you execute constant authentication it will always expose the website’s cookie. For security reasons we cannot do away with authentication and leave it open since everyone would virtually access even the most secured information. To protect the website and online application, instead of single cookie authentication, why not make it a double submit cookie authentication. This trick is possible only in an Ajax based application so hackers will have to work double time to think about the work around for this trick.

There are two ways of protecting your cookie authentication. First, developers can run simple authentication, which is usually before the post. The security measure does not end there. Once authentication has stopped, another function is launched which has stricter version of the rules. It has specific rules that virtually prohibits from suspicious looking cookies to access the website.

There is another version of cookie authentication which also ensures that the website is protected from undesirable cookies. Instead of checking for cookies as they come, developers can develop a website that cookie authentication is requested by the incoming application.

Developers are also required verify incoming cookie to have the value that the server is looking for before any request for information or function is made. This ensures that only trusted domains will access the website which has the actual value the website is looking for. The good thing about this function is that it automatically enables JavaScript in websites and functions that are trying to access the server and application. JavaScript by default will never allow any image linking much less cross-site request forgery.

These two security measures, makes sure that the website is safe enough to accept any cookies and weed out all the possible intruders. Although JavaScript does not allow image linking, there are still other ways of accessing cookie and ultimately hack the website. We will look at most of them one by one in order to protect the newest language that proves RIA could work even better.

Posted by MixedSoup | No Comments »

Introduction

Ajax is the acronym for Asynchronous JavaScript and XML. However, rather than functioning as an acronym it better describes a technique for producing faster, more interactive, and usable web pages that don’t require re-loading every time a user changes a request. This is accomplished by increasing web page responsive-ness through the exchange of small pieces of data by an invisible server. The prerequisites of Ajax are a collaboration of HXTML (Extensible Hypertext Markup Language), CSS (Cascading Style Sheets) that help represent the markup language, client-sided description languages like JavaScript, objects like XMLHTTPRequest that allow the asynchronous transfer of data, and the formatting provided by XML (Extensible Markup Language).
Again, Ajax is a technique, not an object. Jesse James Garrett coined Ajax in 2005 in a presentation to clients. The components that make up Ajax existed well before they were implemented to increase web page usability. This article will describe the development of the components that make up Ajax and their uses.

Background

As aforementioned, the components that provide the framework for Ajax execution include the following: 1) HXTML, that blends HTML and XML functions, 2) Cascading Style Sheets (CSS) that present markup languages intelligibly and style web content, 3) client-sided description languages like JavaScript, 4) XMLHTTPRequest objects.
HTML (Hypertext Markup Language) is the primary markup language for web pages. Markup languages represent text and extra information about the text that corresponds to structure and presentation. Originally conceived by the on-line publishing industry to interact with manuscripts, markup languages transitioned into the digital age through HTML. HTML describes the structure of certain web page text and further complements that description with interactive forms and objects that affect web browser behavior.
XML (Extensible Markup Language) is considered a general-purpose markup language. XML is an open, standard language that facilitates data sharing across information systems, particularly those connected via the Internet. The latest version of HXTML 1.1 became a W3C (World Wide Web Conference) recommendation and, therefore, an industry standard in 2001.
CSS (Cascading Style Sheets) display the presentation of markup written document. This style sheet language, which is also standardized by W3C, presents structured documents whose content is reusable in a variety of contexts. Content can be attached to different logics to create different presentations of the same data. Style sheets have existed since the 1970’s and SGML (Standard Generalized Markup Language). CSS Level 1 became usable in 1996. By 1998, CSS Level 2 was W3C recommended. As of 2006, CSS Level 3 is still under development. The main CSS contribution allows a document’s style to be influenced by multiple style sheets. The cascading effect comes from the ability of style sheets to ‘cascade’ from one another, inheriting a stylistic mixture determined by the site designer and user.
Javascript is a scripting language created to enable prototype-based programming. It is most popularly used for web sites. Its only similarity with Java the programming language is its C syntax. Javascript was developed in 1995 and trademarked by Sun Microsystems. It was licensed for use with Netscape Communications when Netscape began to support Java technology in its Netscape Navigator web browser. Currently, Javascript also operates for other entities like the Mozilla Foundation. As of 2006, the latest model of this scripting language is Javascript 1.7.
XMLHTTPRequest object allows for the asynchronous exchange of data between the server and the client. It is an API (application program interface) that uses Javascript to transfer text data like XML using HTTP (hypertext transfer protocol) thereby establishing independent communication between the server-side and client-side of a web page. Microsoft developed it in 2000 as a part of Outlook Web Access. Mozilla incorporated XMLHTTPRequest in 2002 and Apple incorporated it into Safari 2.1 soon after.

Uses

The uses of these Ajax components work together to allow for automatic, user-based alterations of web pages. As an application of HTML in XML, XHTML allows for automated web processing through the use of the standard XML library. CSS is primarily used to stylize web pages and making them more easily understandable to users. Javascript allows accessibility to the DOM (Direct Object Model) to allow for dynamic information presentation and increased interactivity. The DOM is a standard object model that renders HTML, XML and other related formats. XMLHTTPRequest is important in Ajax web development techniques to increase web page responsiveness and interactivity. For example, it is currently used in Google’s Gmail services and MapQuest among other highly interactive sites.

Points of Interest

The technologies outlined above work together to comprise Ajax programming. The primary benefits of this suite of technologies allow users to access and create web applications more quickly with a level of responsiveness usually attributed to desktop applications. This increased responsiveness is coupled with increased interactivity that doesn’t make it necessary for the web page to reload every time a user makes a new request of the web application.

Posted by MixedSoup | No Comments »

More and more Ajax developers are choosing JSON for their data transfer instead of XML. Although XML has been the pillar of Ajax (X is for XML), JSON has become the choice of most developers because it was particularly built for JavaScript. Compared to XML, JSON is lighter and will work faster compared to XML. This lightweight function enables Ajax based websites and applications to run faster.

The reason why JSON is very efficient in data transmission is its ability to function in itself. By this function we mean that JSON has the ability to “EXECUTE” without the aid of other functions. XML is only a format which will be used to transmit data and files, but JSON is very effective in terms self execution.

Instead of using additional codes and functions from the framework and the server, JSON will basically work on itself and EXECUTE when available. The combination of JavaScript and JSON wherein they function independently and work at the same time makes JSON a perfect pairing for Ajax.

However, the fact that JSON is self executing has made JSON one of the most popular tools for hacking Ajax websites and applications. In previous blogs, we have pointed out one of the biggest problems in Ajax is Cross Site Request Forgery or CSRF. With this function, the hacker has the ability to control not only the data of the program but with the general functions as well. All the hacker has to do is to upload a file with a malicious JSON code and let it run through. In no time at all, JSON should be able to access the server and take over the controls and functions of the applications.

When you opt to use JSON in your Ajax based site or application, be sure to build JSON in a very secure environment. You have to use this especially when your application’s content is based on the user uploads. Anyone who has basic knowledge of JSON and simple application could easily hack the system and extract the content of your server and objects transmitted.

To ensure your JSON is secured, consider registering the types of JavaScript class that goes inside your system. The server will screen everything that goes in and if something is not according to the class that you specified, it will flag and will give you the ability to review the incoming content.

Another trick that you can use in your JSON is to register it according to the class type you specified and then brace it with another function. Imagine JSON being wrapped with another function so that it will not be detected by the hacker. They will just keep on guessing the exact class of JSON you will be using which could take forever. You will have to manually encode each JSON which could take some time. However, considering the security it will add, the time spent in securing data is worth it.

Always secure your JSON, it is the most convenient data mark-up you will use but it is prone to different security problems that you should cover up before implementation.

Posted by MixedSoup | No Comments »

Introduction

Ajax frameworks support Ajax technologies to build dynamic, client-side web sites. On dynamic web pages, users can make requests of a database contained on a server. Within an Ajax framework the data is sent to or read by the server through the use of JavaScript. This allows users to make specific requests that are processed and implemented using dynamic factors like specific user input, time of day or search history to determine the content of the web page. While Ajax is primarily a client-side set of technologies, the Ajax framework facilitates server-side processing such as the finding and storage of data. The goal of the Ajax framework is to function as a communication layer between user and server. This framework, which is specially designed to handle Ajax requests, lets Ajax perform its function of reducing user wait time while the web page accesses the server.
This article will discuss the development of the Ajax framework as described by Jesse James Garrett, the man who gave it its name. A brief description of different types of frameworks will follow. This discussion will define direct Ajax frameworks, Ajax component frameworks, and server-driven Ajax frameworks. Finally, this article will suggest other Ajax frameworks that are server independent.

Background

In 2005, Jesse James Garret wrote an article for his company Adaptive Path entitled “Ajax: A New Approach to Web Applications” where the components and goals of Ajax were defined. In it, he describes the discrepancy between desktop applications and web applications. The impetus behind Ajax was to provide web pages with the technology to make them as rich and responsive as desktop applications. The most powerful real-time manifestation of this responsiveness is how Ajax technologies don’t require complete web page reloading every time a new request is made or new data is entered. J.J. Garret defines Ajax as many existing technologies powerfully coming together to create a new user experience.
The components include the following: 1) a presentation based on industry standards using XHTML (Extensible Hypertext Markup Language) and CSS (Cascading Style Sheets). 2) Dynamic and interactive application of DOMs (direct object model). A DOM is a standardized API (application programming interface) that, when implemented in a web browser, allows scripts to access browser elements. DOMs are particularly useful when updating the content, structure and style of HTML or XML documents. 3) Data, contained in databases, must be employed and available for communication and execution of requests. 4) XMLHttpRequest objects conduct asynchronous data retrieval. 5) JavaScript is required to bind all requests so they are intelligible across all Ajax components and multiple platforms.
Ajax frameworks are designed to support these technological requirements and requests. A framework facilitates Ajax programming because for the client uses the highly intelligible and translatable JavaScript to make requests of the server. Meanwhile it searches data, processes request and communicates them to the server through the browser.

Uses

There are three main types of Ajax frameworks. The first are “direct object frameworks”. The second types are “Ajax component frameworks”. The third types are “server driven Ajax frameworks”. The following is a brief description of each one.
Direct object frameworks are usually smaller than the rest. They are used primarily for web site development as opposed to web application development. This is the difference between, for example, on-line shopping site versus a web application like web-based e-mail. Developers must command Ajax, HTML and CSS in this framework, since developers design the pages in HTML and the framework deals with APIs (application programming interfaces) written in HTML. These APIs facilitate communication across browsers.
Ajax component frameworks are larger and generally apply to web applications. They use pre-made components to generate and apply HTML. Ajax component frameworks allow for more rapid development and require less control. Certain structures like grids and tabs are provided, but user input forms must be written in HTML/CSS through Ajax techniques. Other incarnations of this framework only require general XML or JavaScript literacy. Component frameworks provide customized APIs, allow dynamic program control based on user input, and create new components based on existing ones.
Server-driven Ajax frameworks use components developed by the server using server-side languages. User requests are communicated to the server through Ajax techniques. This requires the developer to be literate in both Ajax and server-side code. These frameworks are more useful for server-side developers. However, they can be busy and overloaded since one function may require many server-side requests. Frameworks running through browsers, unlike server-driven frameworks, provide greater scalability. Server-driven frameworks require developers to know which parts of the presentation the client handles and which are handled by the server. JavaServer Faces and Google’s GWT (Google Web Toolkit) are examples of server-driven frameworks.

Points of Interest

Ajax frameworks provide a complete library to construct web applications through the Ajax engine, i.e. the suite of technologies that facilitates communication between user requests and server without the lag-time and work it takes to re-load the entire page. Other types of Ajax frameworks include JavaScript and server technology independent frameworks, .NET frameworks, and PYTHON frameworks.

Posted by MixedSoup | No Comments »