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


#1

I use openfire server with AD authentication, and whenever I need the AD server becomes unavailable (due to a restart, for example), all connected Jitsi users are dropped due to lack of authentication (which is OK) but the cached saved password is lost, and users get a box like this:

https://cdn.pbrd.co/images/oqBiMt6.png

After the AD server is back, there are lame users (most of them) that doesn't remember to log in again and/or to check the "remember password" box, which results in lots of users becoming offline, needing technical support interaction for getting back online again.

Can't we have an option to make:

B: an auto reconnect countdown
A/B Example: https://cdn.pbrd.co/images/or0t9Kv.png

C: a "stealth" mode, where jitsi keeps trying to reconnect as A/B example but the window popup asking for password is hidden. Maybe for this mode jitsi would change color on the task bar, meaning it's trying to connect.

Thanks

Cassio

···

A: the checkbox continue to be checked and the password filled

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


#2

This problem is really serious for us.
Another situation that causes it is when roaming users on laptops hibernate for the night. When they wake up the laptops the next morning, AD is not immediately online, so Jitsi fails and forgets their password.

This happens EVERY SINGLE DAY.

50% of people on my server will not use Jitsi because of this. Not out of spite, they just don't remember or want to reconfigure Jitsi every single morning. Every time I need to IM someone, I need to call them on the phone to tell them they are "Offline". This renders Jabber useless. Everyone is always offline, so what good is it?

This is a critical problem. I'm just glad I'm not the only one.

Jitsi needs to silently and automatically reconnect, and NOT forget it's configuration.

···

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


#3

My organization has the same problem.

···

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


#4

So, no update on this?

···

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


#5

They're last message was to "use a different jabber client". LOL.
So that's what I did.

···

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


#6

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


#7

I've been using pidgin for windows and adium for mac, where the video isn't necessary, both works way more stable...

···

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


#8

The described problem means that OF returns error with authentication failure, which means username and password is wrong, and there is no reason to try reconnecting. Normally, if just the connection is dropped reconnection will happen.
Logs from such situation (the pcap which is normally in the logs archive) will help determine is there a way to distinct such cases and whether an easy resolution is available or OF sends the same error for authentication errors and the situation you describe.

···

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


#9

damencho, not true in all cases.
In our case, when laptops wake up from sleep, the program tries to reconnect but the firewall proxy agent hasn't connected yet. Jitsi gets a login failure NOT BECAUSE THE PASSWORD IS INVALID, but because the firewall has not yet authorized the session. Then jitsi drops everything.
By the time the network is up and stable, jitsi has already thrown up a screen demanding you enter your username and password. Users get annoyed by this after 50 times and they won't use it.

BTW, other programs do not do this.

···

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


#10

Also, it's going to be difficult to get a pcap because the machine is not even fully up at this point yet. I don't know how I would even start a trace while it is booting up.

···

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


#11

Pcaps are automatically generated by jitsi. You can just send me the archive of logs from Options as described here: https://jitsi.org/logs. This will be helpful to determine the problem.

···

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


#12

oh, in that case I'll try it.

···

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


#13

I could provide pcap files from my machine; I am also affected by this bug. Would that help?

···

--
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-249376341


#14

I have the same problem.

When jitsi wants, to start the program (not always) asks me password.
It's a problem because I have 200 users using this program in my organization.

···

--
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-266396139


#15

I’ve migrated to pidgin, no more problems.

···

On 12 Dec 2016, at 08:41, mirohe <notifications@github.com<mailto:notifications@github.com>> wrote:

I have the same problem.

When jitsi wants, to start the program (not always) asks me password.
It's a problem because I have 200 users using this program in my organization.


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

--
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-266404296


#16

Has anyone managed to solve this? I'm also having the same problem

I believe it is related to network instability, when the desktop network becomes unstable it becomes more likely to lose the password. Is this a jitsi's native function? When the network is unstable it deletes the password from the file sip-communicator.properties

Does anyone have any idea where this function could be in the source code to deactivate 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-266433528


#17

If anyone on the dev team is reading this, this is what you need to do to fix the problem correctly.

First, when Jitsi attempts to connect to the server to login, if it fails to connect, DO NOT ASSUME that means a wrong password. The program should see if it can connect to server, not login, just connect and establish a TCP connection.

This may take several attempts, and up to 5 minutes.

After the connection is established THEN you try to login to the server. Don't go logging in until you have a channel established.

The reason is that many users out there cannot just wake up and instantly connect to the Jabber host the second Jitsi comes up. There are lots of factors that can delay the network connection. Firewall proxies may not be established yet. Also, at work we have NAC. Network Access Control. This prevents network communication until the NAC agent has communicated with a RADIUS server and authorized the computer to connect to the network. This can take a minute. Meanwhile, Jitsi starts up and immediately starts logging in, even though the network is down. Doomed to fail.

These are not edge cases. I have 65,000 users here at work that are all on NAC. At home, our workstations cannot start talking until the firewall proxy agent is up. Often, Jitsi starts up before the proxy agent, then it fails.

If anything I said is not clear, just say so and I will be happy to explain further.

···

--
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-266437749


#18

if it fails to connect, DO NOT ASSUME that means a wrong password. The program should see if it can connect to server, not login, just connect and establish a TCP connection...
If anything I said is not clear, just say so and I will be happy to explain further.

Yeah, I understand what you mean, that's what happens in my office.

I do not understand how they do not solve this problem, I think it should not be difficult

What did you do to "solve" this problem? I thought about creating a gpo that would only read the file sip-communicator.properties

···

--
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-266468193


#19

I solved it by switching my users who use hibernate to pidgin.
I took a look at the code and was going to try and fix it myself, but I couldn't get it to compile.

I really think this is just a one-line fix. At least to stop it from clearing the credentials...

···

--
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-266469638


#20

I really think this is just a one-line fix. At least to stop it from clearing the credentials

Really, should be something simple.
But I do not even know where to start looking for this, I do not know Java

···

--
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-266472208