Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to pick SASL auth type? #808

Open
kriegster108 opened this issue Dec 29, 2019 · 8 comments
Open

No way to pick SASL auth type? #808

kriegster108 opened this issue Dec 29, 2019 · 8 comments

Comments

@kriegster108
Copy link

kriegster108 commented Dec 29, 2019

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

@sonnyp
Copy link
Member

sonnyp commented Dec 29, 2019

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

@kriegster108
Copy link
Author

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

@sonnyp
Copy link
Member

sonnyp commented Jan 2, 2020

@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 ?

@yuanchieh-cheng
Copy link

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.

@sonnyp
Copy link
Member

sonnyp commented Jan 19, 2020

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?

@yuanchieh-cheng
Copy link

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 ?

@sonnyp
Copy link
Member

sonnyp commented Jan 20, 2020

@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?

@yuanchieh-cheng
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants