Guenther Niess wrote:
Should this workflow use the HTTP Auth method as described in the RFC
(basic or something else)?
After thinking a bit, I noticed that it would be really hard to fit this
protocol flow into standard HTTP auth methods.
In normal HTTP auth methods:
1. server sends you a small amount of information
2. you send back much.
But in our case:
1. server sends much (realm, jid, id)
2. user sends back... nothing over HTTP!
So the problem with using things like Basic auth, server would have to
put everything into realm, user would have to read this quite long text,
type jid and id by hand (I don't think most of browsers allow you to
copy realm) and then accept empty dialog box..
And also: I disliked the idea of "abusing" realm in XEP-70, but in this
case I'd really hate it. Because realm would be different every time.
Alternative option is to define new HTTP auth scheme. This is probably
the "right" way to go, but... it *requires* browser support, as there
will be no backward compatible mode.
Yet another alternative is to change protocol flow:
1. server sends you auth agent JID (and only this) as realm
2. users asks agent (via XMPP) for one-time-tokenn/password
3. users provides this token as HTTP auth password (leaving username blank)
Advantages are:
* Multiple realms supported! Just use different auth agent JID for each
realm. And xmpp:[EMAIL PROTECTED] is a more acceptable "abuse" of realm
* This is pretty much like original XEP-70, but without spamming problem.
Now of course we could use the same protocol flow for authentication
based on HTML forms (instead of HTTP-headers):
1. website displays agent JID (may be clickable)
2. user asks agent for a token
(these two steps could be automated like before:
xmpp:[EMAIL PROTECTED];body=give_me_token) and agent sends it
back in a message
3. user does copy/paste and logs is.
Honestly, this was my initial idea. But then I thought: if I replaced
"give me token" with "give me token, my session id is 1234", then server
could proceed with authentication without user pasting the token back to
the browser.
Is someone working on the XEP? If not, then I would start writing a
draft, but I think I need some help.
My draft of this Informational Tip-of-the-Day XEP would be:
To bind XMPP identity to HTTP "session"(*), display a opaque token on
your site and ask visitor to send it to you via XMPP, using his/her
desired JID. End ;)
(* - I know that there is no such thing as HTTP session, but somehow it
works in "real life")
Of course, if we want a solution that may be automated, adding <link
rel="xmppauth">, etc could help.
--
Maciek Niedzielski
xmpp:[EMAIL PROTECTED]
