On 4/5/10 4:01 PM, Aaron Kryptokos wrote: > Nathan Fritz wrote: >> By not using the same node as the authentication user, you're going >> against two SHOULD suggestions in the RFC > > I can't find anything in RFC 3920 about this case. Can you help me find > these two recommendations? > >> I would recommend against doing this on a public >> service where you expect any IM client. > > The authentication and authorization system already exists, so my hands > are mostly tied. I'm open to any reasonable implementation that will > make this work. The one design restriction imposed on me is that the > authenticating client must some sort of way provide the authentication > username as part of the process; mapping from the node to auth > credentials is not acceptable.
Hi Aaron, I took another look at your original message in this thread: http://mail.jabber.org/pipermail/jdev/2010-March/088174.html and: http://mail.jabber.org/pipermail/jdev/2009-November/087885.html We had some discussions about a related issue recently on the XMPP WG list: http://www.ietf.org/mail-archive/web/xmpp/current/msg00332.html The conclusion we came to is that the authentication identity is indeed not necessarily the same as the localpart of a JID. We mostly glossed over this issue in RFC 3920, but the replacement RFC will make it clear that this is a matter for the SASL mechanism or local deployment policy, not the core XMPP RFC. > If it's true that the RFC discourages this practice, then I think the > RFC may need to be revised. For people who are running simple > stand-alone Jabber servers, this sort of thing doesn't matter. But for > organizations like mine that are trying to embrace XMPP by adding an > XMPP interface to existing infrastructure, this is a major issue. GTalk > has a variation of the same problem, except with domain instead of > username. I think the real long-term solution here is that the RFC > needs to firmly instruct clients to not make assumptions about their > JIDs, See http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-05 (section 7.2.7). > and instead accept (or reject) what they are given at resource > binding. We could probably strengthen the text about that. >> You >> are, again, in violation of the spec by delivering stanzas where the >> bare jid does not match their bound name, and you could cause >> unintended consequences on the client (crashes or strange behavior) by >> simply pinging them in this way. > > I can't find any prohibition like this in RFC 3920 or the draft. Can > you point out a specific passage that prohibits this sort of probing? I don't see any need for this -- the client needs to get its JID from the server. >> I really don't see either of these options being viable as the client >> is simply broken if it doesn't respond to it's bound fulljid and you >> risk greater consequences if you try to "adjust" at the protocol >> level. > > My main goal is for a short-term, practical improvement in functionality > for as many users as possible. I agree with Fritzy here -- better to file bug reports or provide patches to the clients you care about. Supposedly short-term fixes have a way of lasting for a long time, people start to depend on the fix and it will never disappear. > As an alternative, I'm thinking about perhaps having the user do > something special to indicate that 'JID masquerading' should be > performed, such as placing a special character in their username. Please not. > Another option is to try to detect specific versions that are broken > using XEP-0092: Software Version, and apply the workaround for just > those. This would get correct operations to the largest groups of > users, and prevent breaking people whose clients were in fact operating > correctly. Do you have a list of broken clients? Let's figure out what they are and start the process of reporting bugs and fixing code. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
