Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Is xauth dead? #1

markushausammann opened this Issue Mar 8, 2012 · 4 comments


None yet
5 participants

What happened to the project, are there better alternatives?

chmac commented Dec 17, 2012

The domain xauth.org appears to be down today, perhaps xauth really is dead...

There is a javascript SDK for this on Facebook, more info here:

brettz9 commented Feb 6, 2014

If server load might have been the reason for the site being down, why not put a cache manifest on the HTML so that server load could be minimized (and performance optimized) and also possibly look for a already-trusted host like Mozilla to serve the content (especially since adoption might otherwise be limited given trust issues since the hosting site could potentially manipulate the HTML to retrieve the user's local storage info for all these domains and upload it to their own site)--at least pending a hopeful return of the likes of globalStorage.

(I think it would be even better if XAuth were retooled to not limit itself strictly to authentication; maybe allowing two forms of generic storage, one which would limit editing, but not viewing, and be keyed to origin, and the other allowing fully open read-and-write access to properties of a storage object allowing any form of namespace (URL, URN, arbitrary string, etc.) as keys and an object required at the top level as value. The domain or namespace keys would lead to objects at the top level as opposed to other data types in order to avoid accidental conflicts (such as one site overwriting an existing namespace object with a boolean or array) in case someone wanted to shape sub-namespaces of the main namespace in a different way--if they chose a suitable key, they would further minimize the chance of conflicts. But the sub-namespaces could contain any kind of data type.)

My feeling is that the big players might feel threatened by something like globalStorage as data could end up being the property of the user again (as in the days when most data was accessed from local files on disk), so hopefully a privacy advocate like Mozilla could be convinced to at least do something which brings data ownership back to users instead of succumbing to the alarmist idea that shared resources are inevitably not worth the potential risks to security or privacy. We already had this before with something we knew as desktop files that can be opened by other applications, and that worked and works pretty well!

Another alternative, albeit a regrettably non-standard and currently Firefox-only one, but one not suffering from remote hosting-related privacy/security and performance concerns, is via my AsYouWish Firefox add-on (namespaced storage demo or for an (arbitary) file-based retrieval demo).

m93a commented Feb 22, 2015

If data URIs had their own domain (and were allowed to use localStorage), this code would be a server-less solution:


  // Technologies used:
  //  * data uri
  //  * cross-origin communication
  //  * promises

  var frame = document.createElement("iframe");
  frame.src = "data:text/html;charset=utf-8,%3C%21document%20html%3E%3Chtml%3E%20%3Chead%3E%20%3Cmeta%20charset%3Dutf-8%2F%3E%20%3Ctitle%3EInterStorage%3C%2Ftitle%3E%20%3C%2Fhead%3E%20%3Cbody%3E%20%3Cscript%3Ewindow.addEventListener%28%22message%22%2Cfunction%28e%29%7Bswitch%28e.data%5B0%5D%29%7Bcase%20%22v%22%3A%20e.source.postMessage%28%220.0.0%22%29%3B%20break%3B%20case%20%22get%22%3A%20e.source.postMessage%28%5B%20e.data%5B1%5D%2C%20localStorage.getItem%28%20e.data%5B2%5D%20%29%5D%2C%20%22%2A%22%29%3B%20break%3B%20case%20%22set%22%3A%20localStorage.setItem%28%20e.data%5B1%5D%2C%20e.data%5B2%5D%20%29%3B%20break%3B%20case%20%22rm%22%3A%20localStorage.removeItem%28%20e.data%5B1%5D%20%29%3B%20break%3B%7D%7D%29%3B%20%3C%2Fscript%3E%20%3C%2Fbody%3E%3C%2Fhtml%3E";
  frame.style.display = "none";

  var pending = [];

  window.globalStorage = Object.create(null);

  globalStorage.get = function(name){
     "get", pending.length, name
    return new Promise(function(r){

  globalStorage.set = function(name,value){
     "set", name, value

  globalStorage.remove = function(name){
     "rm", name

    if(e.source !== frame.contentWindow){ return; }
    pending[ e.data[0] ]( e.data[1] );


Sadly, the W3C standard says that data URIs inherit the document.domain from the page that opened them. Chrome violates this standard making data URIs use their own domain, however it does not allow localStorage for them, so this code is not usable at all.

We have created a fork of XAuth using the same technique, but with a slightly different model. Rather than giving each domain a bucket that only it can write to and everyone can read from, the server provides a manifest that assigns certain local storage keys to certain lists of domains that may read and write to that key. The project's name is cors-light, and can be found here: https://github.com/yarn-co/cors-light.

The API has changed slightly, CommonJS/AMD modules are supported, it uses promises or callbacks, and uses real Errors, etc., but the underlying technique (and much of the code itself) is the same. It's also fully tested 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment