Guenther Niess wrote:
On Tue, Jan 08, 2008 at 01:14:41PM -0700, Peter Saint-Andre wrote:
I was just chatting about this with Maciek Niedzielski and he suggested
a different kind of workflow for XEP-0070-like functionality:
1. User visits www.example.com
2. The website advertises a link to an XMPP-based authorization service,
such as:
xmpp:[EMAIL PROTECTED];body=[some-unique-id-here]
(The message could also include some kind of data form or hidden content
that can't be modified by the user.)
Maybe this link can have two targets, one is the XMPP URI and the other
the requested side which needs the authentification. But I've no idea
how to do this in a nice way.
Probably some kind of javascript would be required..
3. User clicks the link and launchs their Jabber client
4. Jabber client sends an XMPP message to the auth service:
<message from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]'>
<body>[some-unique-id-here]</body>
</message>
I think this message should also include the requested URL. This can
help the website to have more than one realm.
This "unique id" comes from the server, so it's up to server to put
there enough information to know what to do with the message. I don't
think out XEP should define what should be there.
I imagine that a typical implementation would use an opaque id, and
store all needed information server side - when id arrives over XMPP,
server would then look up URL, PHP session id, etc, whatever it needs.
5. The website refreshes with some verification
I'm not sure how this can be done in a nice way. My only idea is via
javascript, but maybe it will be better to work with the HTTP protocol
or something else (In case that at 2. one link with two targets is not
a appropriate solution).
Pure HTTP implementation that I can imagine:
* First link triggering XMPP message.
* Second link (unfortunately, you'd probably need to click twice without
browser-side scripting) opening the desired website. If you check
original XEP-70, server is just waiting for XMPP confirmation before
sending any headers.
If this is not desirable (because we're afraid of timeouts, or because
we think this doesn't look user friendly), it would be possible to use
HTTP refresh and do a "knock knock": if there is no confirmation, server
sends a small page saying "waiting for confirmation over xmpp" with
HTTP-refresh set to - for example - 3 seconds. After 3 seconds, website
refreshes and again: if there is no confirmation yet, server sends this
"waiting.." message, else it sends real page.
And again, I don't think the XEP should decide how this should be done.
Some websites will prefer pure HTTP approaches, other will do something
AJAX-driven. Some will do both. Some will invent something even better ;)
Now the user is authorized at www.example.com (or a particular page there).
Should this workflow use the HTTP Auth method as described in the RFC
(basic or something else)?
The original idea was just about clicking links, as this would require
no browser support and no client support (assuming that URI handling
works, but this is not anything "new". and in the worst case, a website
may say "if this link doesn't work for you, send somethingsomething to
[EMAIL PROTECTED]".
Now, if we want to support real HTTP-level authentication...
We have to ways: either hack around existing schemes (Basic, etc) or
invent new one. Both of them are probably not so great ideas ;) Let me
think a little more about it.
--
Maciek Niedzielski
xmpp:[EMAIL PROTECTED]
