[jitsi-dev] [jitsi] Jitsi loses password when unable to authenticate (#150)


#21

If it would be so easy, we would already have solved it. The problem is not that Jitsi assumes no connection=wrong credentials. @cassioac most likely uses or used Openfire. Jitsi only clears the credentials when the server reports that these are invalid, which also explains the situation with the AD server rebooting.
Simply not having a connection to the server definitively does not trigger clearing the password. I have never experienced this, but I would have on the countless WiFi hotspots which need an acknowledgment on a landing page. Or with the recent internet connection blackouts I had due to a broken cable modem.

If anyone wants to take a look at the "oneliner": start debugging at https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/impl/protocol/jabber/ProtocolProviderServiceJabberImpl.java#L644

If someone can me provide me with an environment that allows reproducing the issue I can and will look at it.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266580342


#22

all my jitsi -> openfire -> AD environments have this problem whenever AD goes offline and openfire can’t communicate with it.

···

On 12 Dec 2016, at 20:57, Ingo Bauersachs <notifications@github.com<mailto:notifications@github.com>> wrote:

If it would be so easy, we would already have solved it. The problem is not that Jitsi assumes no connection=wrong credentials. @cassioac<https://github.com/cassioac> most likely uses or used Openfire. Jitsi only clears the credentials when the server reports that these are invalid, which also explains the situation with the AD server rebooting.
Simply not having a connection to the server definitively does not trigger clearing the password. I have never experienced this, but I would have on the countless WiFi hotspots which need an acknowledgment on a landing page. Or with the recent internet connection blackouts I had due to a broken cable modem.

If anyone wants to take a look at the "oneliner": start debugging at https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/impl/protocol/jabber/ProtocolProviderServiceJabberImpl.java#L644

If someone can me provide me with an environment that allows reproducing the issue I can and will look at it.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/jitsi/jitsi/issues/150#issuecomment-266580342>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAP4SkPqPkS10_4RAfP2u-5f-feF1012ks5rHdE9gaJpZM4F4IhM>.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266613308


#23

@cassioac I'm not sure what Openfire is reporting in that case. It's possible that we do mishandle something, but a service unable to authenticate any user shouldn't accept logins at all. And this case is different from the others mentioned here with the NACs and late network startup.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266865820


#24

Please let me know if you want me to provide any kind of log

···

Sent from my iPhone

On 13 Dec 2016, at 19:22, Ingo Bauersachs <notifications@github.com<mailto:notifications@github.com>> wrote:

@cassioac<https://github.com/cassioac> I'm not sure what Openfire is reporting in that case. It's possible that we do mishandle something, but a service unable to authenticate any user shouldn't accept logins at all. And this case is different from the others mentioned here with the NACs and late network startup.

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/jitsi/jitsi/issues/150#issuecomment-266865820>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAP4Sld-d5lkZxZemk0DUWNr34LKerz6ks5rHwyDgaJpZM4F4IhM>.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266866368


#25

@cassioac I'll have a look if you have a complete set of working vs. non-working logs. You can send them to me directly if you don't want them floating around publicly.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266869904


#26

I haven't done a trace directly, but consider this possibility.
Laptop wakes up from sleep.
Firewall proxy begins to login.
Jitsi starts up and tries to login. Firewall proxy HAS NOT finished setting up yet.
Jitsi gets a 401 something because it is unauthorized to make any network requests - because the firewall is forbidding everything until proxy is up.
Jitsi now deletes credentials and asks user to reenter them.
Proxy has now connected and network connectivity is running.
User scratches head and wonders what just happened.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266871763


#27

@basildane If your firewall proxy hijacks a TLS secured connection and injects a SASL not-authorized response: I'm impressed. And it wouldn't be Jitsi's problem because in this case it would behave as expected.
If there's no connection to the XMPP server at all, then nothing happens. Just like in the case with the WiFi hotspot I described earlier. I can't investigate anything without a proper set of logs from Jitsi.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-266874105


#28

Any chance someone can sends me the .pcap files from an affected client? If not, I'm going to close this issue.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-272665182


#29

Well, I'm totally ignorant but created an account here as I'm unable to login to my two Jabber accounts (keep getting invalid password message). My problem isn't exactly the one this thread describes, but I think may be related. I'm mailing you my .pcap files. Hope this helps.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-278071607


#30

Closed #150.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#event-952898911


#31

@LesterJitsi http://lists.jitsi.org/pipermail/users/2016-April/011051.html

As I got no other logs, I'm closing this issue.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-278156607


#32

Same problem for me.
Getting logged out from SIP Account every other day.

If you are willing to reopen i can provide Logs.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-312857267


#33

I have also seen that if you install a new version of java (always having another installed in the system), or uninstall and install again, it always loses the authentication.

Please, I have 200 users with this problem

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-312860994


#34

@MountainMaster if you can't attach the logs while the issue is closed, please send them directly to me.

@mirohe Your issue is different. Switching Java versions changes the supported ciphers (AES 128 vs AES 256). Jitsi uses AES 256 to encrypt the passwords in the settings if available. If it's not available (which is the case by default in Oracle's Java), it'll use AES 128. Other than generally switching to AES 128, there's nothing we can do.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-312863933


#35

Yes I understand, but also when jitsi wants, to start the program (not always) prompts me for password, and it is not a problem installing or changing the java version.
I wrote this above.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-312897530


#36

The problem is still there: When Jitsi is unable to contact the server (or maybe even gets rejected by the server), it seems to incorrectly conclude that the password must be wrong (it never is), and perhaps even deletes the remembered password (really?), as it keeps asking even when the network connection comes back and you restart Jitsi after that.

And even _if_ the case is that the server erroneously rejects the password, Jitsi should not conclude that the password is _actually_ wrong – it should still suggest the previously used password in the dialog box (dotted out of course in a proper password field, maybe even using a fake temporary password of the same length to avoid password peekers), so the user doesn't have to type in the same password again and again.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-354101081


#37

I don't feel like supplying pcap log files, as they contain sensitive data and shouldn't _really_ be related to this. The problem is about how Jitsi behaves generally in certain circumstances, such as seemingly forgetting the password if it gets rejected by the server. In my mind, Jitsi should _never_ forget the password unless the user specifically asks Jitsi to forget. So even if the server actively rejects and says unauthorized, Jitsi should _not_ forget the password, as the server might be wrong (there are bugs in server software too). If there is disagreement about this behaviour (forgetting the password or not), it should be an option.

Even though I will not supply the entire pcap files, you are most welcome to ask me questions about the pcap log file for a session where this has actually happened. Then I'll look up that specific information. :slightly_smiling_face: I saved one of those pcap files in a safe place.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-354102922


#38

@jhertel The .pcap's obviously don't contain the actual password, but I understand that you don't want to share other details.

Jitsi is erasing the password because it is currently the only way to bring up the password dialog during the next logon attempt. I don't disagree with you that this feels wrong, but I also don't have an easy fix/workaround. There's at least these cases to consider:
- The password is actually invalid
- The password is valid, but has expired and cannot be used to login anymore
- The password is valid, but the server says otherwise
Simply retrying (as has been suggested either here or in another issue, I can't remember) might trigger an account lockout due to repeated retries.

Since the problem never occured to myself, I was unable to capture a proper trace to at least soften the symptoms. However, if a server is known to behave faulty (e.g. replying `not-authorized` instead of `temporary-auth-failure`, which is what _might_ happen in some cases, e.g. when an LDAP server/AD domain controller is unavailable), then that should be fixed too.

Those who can compile Java and have the problem repeatedly: does it also happen with the smack4-2 branch? The Smack update might bring some relief. Otherwise, help on implementing a change would be very welcome!

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#issuecomment-354124871


#39

Reopened #150.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/150#event-1402592212


#40

Well, after searching a good alternative for skype i tried jitsi too. But it has a lot of issues and nobody helps.
Maybe the developers are just overloaded with tasks.
So use a different client how it is recommended :smiley:

Maybe jitsi will be better in some years, so try it later again.

···

Am 02.01.2016 um 19:36 schrieb cassioac:

yeah I would rather also, but only jitsi has video, it's sad it has such poor support for other issues...


Reply to this email directly or view it on GitHub <https://github.com/jitsi/jitsi/issues/150#issuecomment-168415234>.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus