Patches for build.xml / SASLAuthentication.java / SASLGSSAPIMechanism.java

Smack Smack Dev
1

Hi,

i have here some patches:

  1. for an typo or an directory change in build.xml (jingle-extension -> jingle/extension)

  2. SASL Authentication must work against the Hostname for kerberos support (is documented right in code but done wrong )

  3. SASL GSSAPI Mechanism gss.conf part extended to check, if a config is already set, we doesn’t change it. if not, we set our gss.conf with the currenty working directory.
    build_xml.patch.zip (484 Bytes)
    SASLAuthentication_getHost.patch.zip (586 Bytes)
    SASLGSSAPIMechanism_gss_conf.patch.zip (1063 Bytes)

2

Thanks for the reports

FYI 2. is already known as SMACK-344

But from what I can see in the issue is that using getHost() raises problems on other SASL based auth methods.

3

In the SVN Revision 13060 it isn’t fixed?!.

Only for authentication without an password and callback Handler.

The problem is in the second public String authenticate(String

username, String password, String resource)

if you want to establishe a connection with kerberos and a username /

password pair.

4

In the SVN Revision 13060 it isn’t fixed?!.
Well SMACK-344 Status says “open”, so it isn’t fixed.

Only for authentication without an password and callback Handler.

The problem is in the second public String authenticate(String

username, String password, String resource)

if you want to establishe a connection with kerberos and a username /

password pair.

Sorry I am not really into kerberos auth with smack: What excactly is the problem? Maybe this is a different issue than SMACK-344.

5

Oh okay. I haven’t looked for the state.

The only problem is, that in this two authenticate methods are the same

comments:

// Trigger SASL authentication with the selected mechanism. We use

// connection.getHost() since GSAPI requires the FQDN

of the server, which

// may not match the XMPP domain.

But in the second authenticate is connection.getServiceName() instead of

connection.getHost().

I think also (like you) this bug (SMACK-344) will address this error.

My problem is only, that in the first authenticate it is correct, so i

have thought it is a copy paste error

But it is definitively a bug

I will provide the next time some reworks to DNSUtil to resolve realm

and kdc names from DNS.

Also an patch for the gss.conf so we doesn’t need anymore a config file.

Did you know s.th. about a threading problem with the DNSUtil class?