Home
vgs_rss' Journal -- Day [entries|friends|calendar]
vgs_rss

[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Working with Web Services with ease; dojo.data and the WikipediaStore [28 Jun 2008|09:22pm]
13:50 27.06.2008
Working with Web Services with ease; dojo.data and the WikipediaStore

Revin Guillen has posted about the Dojo dojo.data API and how you can layer access to Web services in a very elegant way.

His example shows building access to Wikipedia (demo):

Dojo recently received a new data store that demonstrates exactly what we want: dojox.data.WikipediaStore. It does just what it sounds like, turning Wikipedia into a simple object you can query from your code. Building it with Dojo’s handy dojox.rpc package makes for a simple, compact, DRY implementation.

In only four steps:

  1. Create the web service object
  2. Declare the new data store, inheriting from ServiceStore
  3. Give it a fetch method
  4. Give it a _processResults method

The service descriptor looks like:

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. {
  3.     "SMDVersion": "2.0",
  4.     "id": "http://en.wikipedia.org/w/api.php",
  5.     "description": "Wikipedia API",
  6.  
  7.     transport: "JSONP",
  8.     envelope: "URL",
  9.     additionalParameters: true,
  10.     target: "http://en.wikipedia.org/w/api.php",
  11.     parameters: [
  12.         { name: "format", optional: false, "default": "json" }
  13.     ],
  14.  
  15.     services: {
  16.         query: {
  17.             parameters: [
  18.                 { name: "action", type: "string", "default": "parse" }
  19.             ]
  20.         }
  21.     }
  22. }
  23.  

which you can use when you create the store:

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. dojo.require("dojo.io.script"); // for cross domain JSONP
  3. dojo.require("dojox.rpc.Service");
  4.  
  5. dojo.addOnLoad(function(){
  6.     var mu = dojo.moduleUrl("dojox.rpc.SMDLibrary", "wikipedia.smd");
  7.     var wikipedia = new dojox.rpc.Service(mu);
  8.  
  9.     wikipedia.query({
  10.         action: "parse",
  11.         page: "Main Page"
  12.     }).addCallback(this, function(article){
  13.         dojo.body().innerHTML = article.parse.text["*"];
  14.     });
  15. });
  16.  

read more at Ajaxian
post comment

dragtable: drag-and-drop reorderable columns for an HTML table [28 Jun 2008|09:22pm]
14:20 27.06.2008
dragtable: drag-and-drop reorderable columns for an HTML table

Dan Vanderkam has announced a new component dragtable:

Over the past several years, Stuart Langridge’s sorttable Javascript library has found widespread use. It’s easy to see why. Just add class=sortable to a table tag and its column headers automatically support click to sort. Pretty slick.

But sometimes sorting just isn’t enough. What if you want to focus on just one or two of the columns in a table? In a client-side application you could drag the columns you care about next to each other. Why not in a web application?

Enter dragtable. Like sorttable, it teaches HTML tables a new trick through a simple class attribute.

Once you have the JavaScript in place, you can simply add a class="draggable", and you can even work with both via class="draggable sortable"

Take a peak at a test bed, and the open source project.


read more at Ajaxian
post comment

The fight for cross domain XMLHttpRequest [28 Jun 2008|09:22pm]
14:24 27.06.2008
The fight for cross domain XMLHttpRequest

There is a thread going on secure cross domain requests. Microsoft came out with a paper saying that the W3C standard isn’t secure, and pushing the Microsoft XDR spec:

A few proposals and implementations exist like XDomainRequest in IE8, JSONRequest and the W3C’s Web Applications Working Group’s Cross Site XMLHttpRequest (CS-XHR) draft specification, which combines an Access control framework with XMLHttpRequest or other features. While XDomainRequest is focused on enabling anonymous access of third party public data, Cross Site XMLHttpRequest has added functionality and consequently enables a broader set of scenarios that may appeal to the developer who may choose to use cross domain authentication and access control among other features. As can be expected with securing a large cross section of cross domain scenarios, a number of concerns have been identified with the CS-XHR draft by the web development community, the IE team members and members of the Web Apps Working Group. For a list of our recent feedback on security on CS-XHR and our take on important security principles in cross domain, please read our Security Whitepaper on Cross Domain. The paper also covers best practices and guidance for developers who will choose to build on the current draft if it’s supported by a future browser.

The community quickly jumped on this in the comments, and beyond.

Anne van Kesteren said:

After half a year of waiting Microsoft finally posted their feedback on Access Control for Cross-Site Requests and specifically the way XMLHttpRequest Level 2 works with that. Microsoft blogged about this event. I suggest people read this rebuttal from Jonas on the paper Microsoft published. To be clear, while the specifications are not entirely finalized nobody has so far put forward a viable attack scenario that does not already apply when these technologies are not supported by user agents.

(Related: Working group fun and “Concerns” raised about W3C Access Control spec have been little more than FUD.)

As linked from Anne, Jonas posted nice feedback:

I’ll start with a mini FAQ to avoid repeating myself below:

Why is the PEP in the client rather than the server?

In order to protect legacy servers some of the enforcement will have to live in the client. We can’t expect existing legacy servers to all of a sudden enforce something that they haven’t before.

In fact, even XDR using client side PEP. It’s the client that looks for the XDomainRequest header and denies the webpage access to the data if the header is not there.

In fact, Access-Control does allow full PEP on the server if it so chooses by providing an “Origin” header.

Is Access-Control designed with “Security by design”

Yes. In many ways. For example Access-Control does not allow any requests to be sent to the server that aren’t already possible today, unless the server explicitly asks to receive them.

Additionally Access-Control sets up a safe way to transfer private data. This prevents sites from having to invent their own which risks them inventing something less safe.

Thirdly, Access-Control integrates well with the existing HTTP architecture of the web by supporting REST apis and the Content-Type header. This allows existing security infrastructure to inspect and understand Access-Control requests properly.

What about DNS rebinding attacks.

Even with DNS rebinding attacks Access-Control is designed not to allow any requests which are not possible already in todays web platform as implemented in all major browsers.

Especially the last point is something that seems to have been misunderstood at Microsoft. It is not the case that DNS rebinding attacks affect Access-Control any different than it affects the rest of the web platform.


read more at Ajaxian
post comment

navigation
[ viewing | June 28th, 2008 ]
[ go | previous day|next day ]