Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5
3. Security Issues
The XMLHttpRequest object is restricted to run within the browser’s security sandbox. Any resources requested by the XMLHttpRequest object must reside within the same domain from which the calling script originated. Therefore the XMLHttpRequest object is constrained to requesting resources that reside within the same domain from which the script was originally served. The W3C states, that in the future The XMLHttpRequest Object specification will define a way of doing cross-site requests.
There is an overabundance of online documentation stating that Ajax introduces multiple security threats. These threats include fake requests, denial of service, cross-site scripting (XSS), reliance on client-side security, and more. Jeremiah Grossman’s article, Myth-Busting AJAX (In)security, maintains that these security issues existed before Ajax and the recommended security best practices remain unchanged. Part of internet security basics is to distrust the client. Ajax is a client side technology and requests need to be treaded with the same caution as all other calls.
4.1. Usability Problems
Web users have become familiar with using classic web pages. Users have become accustomed to using browser features such as the back and next buttons. Ajax calls are not loaded onto the browsers navigation stack. Therefore the back button will not undo the last ‘Ajax operation’. Developers need to explicitly cater for undo operations.
Ajax enabled pages have a notion of state; this state is altered as the user navigates through the site. The browser is unaware of this state, and it is not reflected in the address bar. Therefore users are not always able to book mark a certain page state. Developers need to consider this when deciding on when to use Ajax.
The asynchronous nature may make page updates difficult for the user to notice. The developer needs a way of drawing the user’s attention to the modified section of the page. The ‘yellow-fade technique’ has become common practice. In this technique the changes are highlighted with a yellow background, and the yellow fades gradually. These and other techniques are becoming familiar to web users.
About a week ago I noticed some incoming links from Computer Weekly.com. I assumed that someone had commented on one of my posts, so I browsed there wondering if it was a positive or negative comment. Once the page loaded, I was completely surprised. It turns out that this blog has been short-listed for the Computer Weekly.com IT Blog Awards! This came as a complete surprise to me.
This blog had really humble beginnings. In fact it was not even my idea to start a blog, it was my work that encouraged me to start one. Initially I felt that I did not have that much to contribute to the world at large. In fact I still don’t feel that my blog is as innovative as some others, although judging by the response to my ‘Routing In Rails Tutorial‘ it appears as if I do have a nice way of explaining things. I guess this is one of the main reasons I have been voted onto the shortlist.
The competition ends on the 31st of July 2008. If you would like to vote please go to this on-line voting page. This blog can be found under the ‘Programming and technical blogs’ drop-down list. It is a surprisingly painless exercise, it takes less then a minute and no registration is required.
Thank you to all of you who have voted for this blog.
In part 5 we looked at RESTful routing. In this part we continue to explore RESTful routing, by examining nested resources.
I originally planned to cover nested routes and to cover two questions posted to me in previous comments and emails. One question was with regards to ‘one to many relationships’ e.g. an album has many songs. The second question was from Tom in part 3; this was about adding save as functionality.
In trying to answer these questions I created a new application – a text editor with a version history. This has turned out to be a fairly interesting piece of work. I then changed my mind and decided to include it in a follow up post. I am hoping to have that out later this week (before Friday the 11th of July). As the ‘follow up’ post will have a practical example of nested resources, this post will not have the usual practical section with the experiments.
Introduction to Nested Resources
The Nested URI
Returning to the familiar Music Store application, imagine we added songs to the application. Like Albums, Songs are resources and we could expect to access a song with this URI:
We could then perform the required CRUD operations on that URI based on the REST API as discussed in part 5.
An album has many songs. We can express this within the URI e.g.
Once again we could make use of the HTTP verbs to perform CRUD in a RESTful way.
In this particular implementation, this URI does not mean that this is the 124th song of album 10 – it is possible for it to be the fist song of album 10. The URI is pointing to the 124th song in the system.
If we wanted the URI to state the songtrack number of the specified album then we could alter the above implementation. Then we could expect to see URIs of:
This would not result in a URI conflict.