Host-Proof Authentication?

Abe Fettig’s done some important experimenting to arrive at a direct remoting technique, one which bypasses the need for a Cross-Domain Proxy and doesn’t rely on cross-domain On-Demand Javascript. Compared to the latter technique, Abe’s idea is more functional, because you get the power, expressivity, and bidirectional capability of XMLHttpRequest, as opposed to the On-Demand Javascript hack, which only allows downloading, though you could perhaps pass CGI arguments with the script request, or use one of the image/stylesheet hacks to get information in the other direction.

If we can bypass the server. then we can consider the idea of Host-Proof Authentication. It’s based on Richard Schwartz’s Host-Proof Hosting idea, where encrypted data is decrypted on the fly in the browser. In similar vein, if you needed third-party authentication, these remoting hacks are one way to keep your password away from the prying eyes of the server host. A while back, one of the internet banks (egg?) copped it for asking users to give them all their cusomter IDs, passwords, etc., so they could provide a one-stop-shop service. Maybe Host-Proof Authentication would be a better approach – if not automated, a portal could be set up to allow users to shuffle funds around within the browser.

Back here on Earth, I wouldn’t in reality use Host-Proof Authentication for a critical application – not without a lot more consideration – because there are two reality checks:

  • Host-Proof Hosting is far from perfect– Alex Russell has noted it’s vulnerable to script injection attacks. See the comments in the above links for more on that. Similar comments apply to Host-Proof Authentication.
  • All these direct remoting techniques rely on some form of co-operation with the external server. e.g. Abe’s technique requires it to explicitly set the document.domain property; On-Demand Javascript requires it to expose appropriate scripts; image remoting requires the script to recognise any variables and output an invisible pixel; etc. The external API would have to explicitly let the browser perform remote authentication.

Basics of Ajax 2 of 3: Web Remoting (XMLHttpRequest etc) (Podcast)

Ajax Basics 2 of 3

This is the second of three podcasts on the basic Ajax patterns.

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – Events and Timing.

Podcast 2: Web Remoting (XMLHttpRequest, IFrame, HTTP Streaming)

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

This 75 minute podcast covers web remoting concepts and the following specific patterns:

  • XMLHttpRequest Call Use XMLHttpRequest objects for browser-server communication. (05:00)
  • IFrame Call Use IFrames for browser-server communication. (31:45)
  • HTTP Streaming Stream server data in the response of a long-lived HTTP connection. (47:00)


Please ignore this bit, I’m claiming My Odeo Channel (odeo/bdd768d9acefcad9)

New Patterns: XMLHttpRequest Call and IFrame Call

Full drafts are now online for the two big Web Remoting patterns: XMLHttpRequest Call and IFrame Call. There are also a couple of new demos to illustrate GETting and POSTing with both call types: XMLHttpRequest Example, IFrame Example.

A few extracts follow, but first, let me ask you: Do you know of any public IFrame remoting examples? Google Maps is the only public example I know. All the other examples here are tutorials and framework demos.

The XMLHttpRequest alternatives was the most fun thing here (headings shown below). I went through the various techniques I’ve seen, read about, and tried out, to list as many ways as possible to programmatically call the server. As you might expect for these “Foundational Technology” patterns, there’s a lot more code in the Solutions than in later patterns, where the focus shifts more towards the -ilities, particularly usability and maintainability.

As usual, feedback much appreciated. (Mainly on the content, rather than woeful spelling and outright grammatical disasters at this stage.)

XMLHttpRequest Call

Solution: Use XMLHttpRequest objects for browser-server communication. XMLHttpRequest is a Javascript class capable of calling the server and capturing its response. Just like a browser or a command-line web client, an XMLHttpRequest issues standard HTTP requests and grabs responses. Note: The code shown throughout this demo is closely based on an online companion demo (http://ajaxify.com/run/xmlHttpRequestCall/).

The above example hopefully illustrates that the fundamental technology is pretty simple. However, be aware that it’s a very basic usage, not yet fit for production. Fundamental questions remain:

* How can XMLHttpRequests be created?
* How does an asynchronous call work?
* How do our code detect errors?
* What if the service requires a "POST" or "PUT" request rather than a "GET"?
* Which URLs can be accessed?
* How can you deal with XML responses?
* What's the API? 

The following sections address these questions and show how the code above needs to be modified. …

Decisions

6.1 What kind of content will web services provide?
6.2 How will caching be controlled?
6.3 How will you deal with errors?

Alternatives:

9.1 IFrame Call
9.2 Persistent Connection
9.3 Richer Plugin
9.4 On-Demand Javascript
9.5 Import XML Document
9.6 Image-Cookie Call
9.7 Stylesheet Call

IFrame Call

Solution: Use IFrames for browser-server communication. IFrames are page-like elements that can be embedded in other pages. They have their own source URL, distinct from their parent page, and it can change dynamically. IFrame Calls work by making the IFrame point to a URL we’re interested in, then reading the IFrame’s contents once the new content has loaded.