Can you send me your full logs?
I’ve posted my warn.log exception. There is nothing of this date in the error.log
You don’t appear to trust the certificate from the server. Did you manually modify the trust stores that you use?
I cannot login either if I select the “use old SSL method” for connecting. Are you using that?
I don’t remember doing that. If it was modified, where it is stored? In Spark’s profile or Windows registry? I have tried fresh Spark profile. I’ve tried in another virtual Win7 machine. Or is it on Openfire? But then again i can’t login to igniterealtime.org either.
No, i’m not using Old SSL method.
Can’t login from my Xubuntu box either.
I think the keystores that you use are the ones that ship with Java (I’m not exactly sure how these things work in Spark, sorry). I didn’t do anything out of the ordinary to get things running. Odd, can’t explain your problem.
I don’t know how exactly it works in Spark either. We just bundle JRE with Spark (the latest version). Speedy had some idea above (code example).
I have tried with Java 7 and older Java 8. Same result. Using Oracle Java. Maybe you have OpenJDK, which works for you?
From what I can tell, I think that the old version of LoginDialog.java used a custom SSLSocketFactory (DummySSLSocketFactory) to accept any certificate. adding TLSUtils.acceptAllCertificates(builder) resolved this for me. However, although this will make spark work like it did before, I think a future enhancement would be to prompt/warn the user of the certificate issue before completing the connection.
Yes, i have filed this 5 years ago [SPARK-1203] Spark should ask user to approve server certificate when in SSL mode - IgniteRealtime JIRA
Either way is bad (accepting all certificates, silently dropping connection if something is wrong). But currently Spark is just unusable with SSL. If this is only with Oracle Java, then it will cover larger part of our userbase. This is probably also related to Spark stopping accepting credentials for some users after update to Java 1.8.0_74.
I think i found the issue im having with GSSAPI with smack4. It looks like the code with the smack provider changed (.package org.jivesoftware.smack.sasl.javax.SASLGSSAPIMechanism)
unlike with the smack3 which I think used servicename, the new version seems to be hostname/cname, but have no idea how to address the change.
speedy, at least file a ticket (Major) and set the fix version to 2.8.0 (so i would see it in the list of fixes for that version as open issue), so it won’t get lost here.
will do! I’m going to do another test or two first to confirm a theory.
Speedy and me did another round of fixes. This should take care of the known issues - except for the GSSAPI one. Let’s find some more
Yay!
Now, to the problems. Fastpath is not starting in the latest build. Same was when we tried to update to Smack 3.4.0. Fastpath part was inside Smack before, but since 3.4.0 it was moved out into separate jar smackx-workgroups. [SPARK-1745] Fastpath plugin doesn’t start after Smack 4 update - IgniteRealtime JIRA
That’s the older ticket [SPARK-1670] Fastpath plugin is not working after Smack 3.4.0 update - IgniteRealtime JIRA
Nice!
Yeah, but it will take some time to iron out all the glitches. Another one [SPARK-1751] Only a few first messages show up and no ther messages come through - IgniteRealtime JIRA
One more [SPARK-1752] Doesn’t show file transfer and screenshot sending buttons in the chat window - IgniteRealtime JIRA