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] _______________________________________________
