One of the thinmgs I would like to do is to interact with Atompub (aka Atom Publishing Protocol) stores in Javascript through the browser. Since this effectively the browser itself interacting with the Atompub server, browser-like authentication methods would be nice. But services like Atompub don’t work nicely with the kinds of authentication methods that normal websites use. One of these is OpenID, which is particularly browser-focused.
From the perspective of a client, OpenID basically works like this:
- You need to login. You tell the original server what your OpenID URL is, somehow.
- The original server does some redirects, maybe some popups, etc.
- Your OpenID server (attached to your OpenID URL) authenticates you in some fashion, and then tells the original server.
- The original server probably sets a signed cookie so that in subsequent requests you stay logged in. You cannot do this little redirection dance for every request, since it’s actually quite intrusive.
So what happens when I have an XMLHttpRequest that needs to be authenticated? Neither the XMLHttpRequest nor Javascript generally can do the authentication. Only the browser can, with the user’s interaction.
One thought I have is a 401 Unauthorized response, with a header like:
WWW-Authenticate: Cookie location="http://original.server/login.html"
Which means I need to open up http://original.server/login.html and have the user log in, and the final result is that a cookie will be set. XMLHttpRequest sends cookies automatically I believe, so once the browser has the cookie then all the Javascript requests get the same cookie and hence authentication.
One problem, though, is that you have to wait around for a while for the login to succede, then continue on your way. A typical situation is that you have to return to the original page you were requesting, and people often do something like /login?redirect_to=original_url. In this case we might want something like /login?opener_call=reattempt_request, where when the login process is over we call window.opener.reattempt_request() in Javascript.
Maybe it would make sense for that location variable to be a URI Template, with some predefined variables, like opener, back, etc.
For general backward compatibility, would it be reasonable to send 307 Temporary Redirect plus WWW-Authenticate, and let XMLHttpRequests or other service clients sort it out, while normal browser requests do the normal login redirect?
Update: Another question/thought: is it okay to send multiple WWW-Authenticate headers, to give the client options for how it wants to do authentication? It seems vaguely okay, according to RFC 2616 14.47.
Automatically generated list of related posts:
- Atompub as an alternative to WebDAV I’ve been thinking about an import/export API for PickyWiki; I...
- Atom Publishing Protocol: Atompub Doing stuff with the Atom Publishing Protocol, I’ve noticed that...
- Hypertext-driven URLs Roy T. Fielding, author of the REST thesis wrote an...
- Javascript on the server AND the client is not a big deal All the cool kids love Node.js. I’ve used it a...
The issue with using vanilla atom and javascript is that javascript is terrible at parsing large xml datasets.
For this reason gdata has implemented a json datatype for use in atom, http://code.google.com/apis/gdata/json.html
I have to say I’m not a fan of their formatting. The way they hack in namespaces on javascript still requires some annoying parsing.
At OSAF we went a different route, our’s is specific to representing EIM in JSON but you’ll see the difference.
http://chandlerproject.org/Projects/EimJsonSpec
-Mikeal
Right now I’m looking at smallish data sets, where the server does most of the filtering. That might be a problem later, I’m not sure. I could imagine just using
"{ns}tag"for namespaces, but I suppose that would bulk up the file some. Still, yes, it means that you have to in effect parse the document to resolve the namespaces. Or use conventions, and then translate if their conventions for prefixes aren’t the same as your own.Still, their simpler translation would make it easier to create a DOM-like facade on top. In fact, it seems quite easy to create something DOM-like in that case. That would be appealing.
I think eventually I’ll find [JSONP](http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/) will be necessary, at which point a JSON format would be nicer (though packing an XML response in a string would also be possible). Anyway, maybe it’ll come up then.
Either way, the issue I’m struggling with isn’t an issue XML or JSON, but authentication.
For large dataset it’s quite likely that the server would use the collection listing as per the AtomPub spec. That could help the parsing. Mind you if only all the browsers were supporting E4X the parsing would look much nicer to everyone.
> But services like Atompub don’t work nicely with the kinds of authentication methods that normal websites use.
I don’t quite understand that statement. AtomPub abides to the HTTP rules and I don’t understand why an AtomPub service would therefore be any different from any other websites out there.
Atompub has all the same problems any web service has when it’s being used by a browser. It’s nothing that special about Atompub, except that it could be a service that browsers actually use directly. Notably few people use HTTP authentication with websites and normal browsers. OpenID doesn’t use HTTP authentication either.
If I redirect an Atompub client to a login page, the client won’t know what to do with that. A human would, because humans can read instructions and understand the login pattern. We need a way for Atompub clients to understand that same pattern.
See http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440 and, possibly more relevantly, the ongoing OAuth effort: http://groups.google.com/group/oauth
Most AtomPub clients out there are not automated and require human feedback, they aren’t different from a browser therefore. For automated authentication not requiring human intervention, you need authentication services like those offering OpenID to come up with such solution. I feel like you put the burden on clients which is not where it should be, the problem comes from auth scheme which have never been really thought out of the browser context.
“Update: Another question/thought: is it okay to send multiple WWW-Authenticate headers, to give the client options for how it wants to do authentication? It seems vaguely okay, according to RFC 2616 14.47.”
It’s allowed, and Google’s GData does it to offer two options for authentication (ClientLogin and AuthSub):
WWW-Authenticate: GoogleLogin realm=”https://www.google.com/accounts/ClientLogin”, service=”blogger” WWW-Authenticate: AuthSub realm=”https://www.google.com/accounts/AuthSubRequest”, service=”blogger”
Hi john,
I wanted to know if openid supports the clientlogin similar to how google supports. if yes do u know the url for the same?
Please reply thanx..