Oops, sorry, wrong attribute :). Got my components and users mixed up. The from was actually in the original spec, so that's why I think something is awry with the clients.
My problem is that some of our clients don't do stuff over SSL (GASP!), so plain-text is a no-no, but a really good idea none-the-less. I think I will go on the from attribute, if not there list everything possible. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Artur Hefczyc > Sent: Friday, October 31, 2008 4:30 PM > To: Jabber/XMPP software development list > Subject: Re: [jdev] Username-based SASL Mechanisms > > Hi, > > The 'to' attribute contains hostname only in the client to server > stream initialization and while > the client SHOULD set it it might not. Even if the client sets the > domain name it is not enough > for you to determine it. > > Version bis8 of the RFC introduces 'from' attribute which might be > exactly what you are looking > for assuming it is adopted by all clients soon: > http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html > > Otherwise I don't really see how you could do what you want. Maybe > enforcing PLAIN-Text > password authentication either sasl or non-sasl for all users and then > using appropriate > authentication back-end by the server based on the user name would be > the best solution. > This is probably what I would do. > > Artur > > On 31 Oct 2008, at 14:38, Jonathan Dickinson wrote: > > > Hi All, > > > > This is a rather strange one. Is there any support for determining > > SASL mechanisms based on the user's name? I [will] have a bunch of > > authentication providers, such as EXTERNAL, SQL, SAP, NTLM, > > Kerberos, Open-Id etc. These can be located on the component itself > > or on another component on the network: it doesn't matter (ooh, you > > should see my framework :)). The thing that I worry about is that > > obviously some components won't support other authentication > > mechanisms (NTLM is a good example of this): so if I just query them > > verbatim for mechanisms there is no guarantee that the client will > > be able to use that mechanism to log in (e.g. Joe might be on the > > domain, but not in the SQL DB, failure if he tries to use DIGEST-MD5 > > - his client may even always fail to log in). > > > > I thought that I could use the "to" attribute on the <stream:stream> > > tag, but another problem arises: most of the blumming client's I > > have analyzed using my server don't put this in the start tag: I am > > sure there is a reason I missed on the mailing list (is there?). > > > > I basically want to say to the components, "does anyone know this > > guy? How do I talk to him?" and if they respond I can aggregate the > > results, if not I can use a predefined list of mechanisms (to fool > > harvesters/hackers). > > > > Maybe I could leave it up to the users to complain to the > > misbehaving client developers? > > > > Thanks guys. > > _______________________________________________ > > JDev mailing list > > FAQ: http://www.jabber.org/discussion-lists/jdev-faq > > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > Unsubscribe: [EMAIL PROTECTED] > > _______________________________________________ > > Artur > -- > Artur Hefczyc > http://www.tigase.org/ > http://artur.hefczyc.net/ > > _______________________________________________ > JDev mailing list > FAQ: http://www.jabber.org/discussion-lists/jdev-faq > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [EMAIL PROTECTED] > _______________________________________________ _______________________________________________ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] _______________________________________________
