xmpp.js icon indicating copy to clipboard operation
xmpp.js copied to clipboard

No way to pick SASL auth type?

Open kriegster108 opened this issue 4 years ago • 8 comments

I am currently trying to connect to my wss server but every time it attempts to connect it tries using authentication other than PLAIN. Documentation states you support all types yet I can’t specify in the client object anything about what type to use? After one attempt in the logs on my XMPP server the auth fails because it is trying to use a type other than PLAIN which is what we currently only support. Need direction here on how to switch out what SASL auth types I can pick

kriegster108 avatar Dec 29 '19 02:12 kriegster108

@kriegster108 what type is the client trying (and failing) to use? which types are offered by the server?

sonnyp avatar Dec 29 '19 12:12 sonnyp

I think you pointed me in the right direction just now. Our server is relatively new and not 100% configured properly... our ‘feature’ response states it can be all three of the main SASL types.. which might be why your library is trying to use the wrong one. I’ll get them to remove the other two types from the server so it might work normally

kriegster108 avatar Dec 29 '19 23:12 kriegster108

@kriegster108 ok - it still looks like a bug with xmpp.js though, could you share the output of https://github.com/xmppjs/xmpp.js/tree/master/packages/debug ?

sonnyp avatar Jan 02 '20 19:01 sonnyp

I have the same feature request to pick preferred auth mech. If @sonnyp consider it is worthy to implement, I could try to send a PR for this.

yuanchieh-cheng avatar Jan 14 '20 04:01 yuanchieh-cheng

So if I understand correctly the use case would be to always use the same SASL mechanism?

I'm torn.

On one hand it is trivial to do with @xmpp/client-core (simply add the only mechanism you wish to use)

On the other hand this is a recurrent request.

@xmpp/client is made for XMPP interoperability/federation, if you have a custom non-standard and/or non-federated setup you should use @xmpp/client-core.

So what I'm thinking is to improve the documentation by making that explicit and adding a "How do I" section with examples for "non standard" features such as forcing SASL mechanism.

@yuanchieh-cheng what do you think?

sonnyp avatar Jan 19 '20 12:01 sonnyp

I would try to use client-core instead of client.
It would be really helpful if there are some examples in documents.

But I saw the xmpp documents and it doesn't mention that client have to use first mechanism server returned. https://xmpp.org/extensions/xep-0034.html I am not really sure whether it violate standard or not ?

yuanchieh-cheng avatar Jan 20 '20 02:01 yuanchieh-cheng

@yuanchieh-cheng XEP 0034 is deprecated, you're looking for https://tools.ietf.org/html/rfc6120#section-6.3.3

Can you please elaborate on your use case? Do you want to always use a specific SASL mechanism or simply add it to the list of supported mechanisms and give it a higher priority than the defaults one?

sonnyp avatar Jan 20 '20 13:01 sonnyp

I trying to use gtalk but gtalk server respond PLAIN at the first order which I don't want to use.

According to the doc,

For example, if the server
   offers the ordered list "PLAIN SCRAM-SHA-1 GSSAPI" or "SCRAM-SHA-1
   GSSAPI PLAIN" but the client's ordered list is "GSSAPI SCRAM-SHA-1",
   the client MUST try GSSAPI first and then SCRAM-SHA-1 but MUST NOT
   try PLAIN

If I’m not mistaken, these words mean that Client can specify the preferred mechanism order list.
Does this mechanism support now ?
This would be the feature I would like to use.

Thanks

yuanchieh-cheng avatar Jan 21 '20 03:01 yuanchieh-cheng