Andrzej Wójcik (Tigase) opened 8 years ago
|
|
It took me a while to understand this issue and to find a root cause of it. Finally, I was able to replicate this issue when websocket connection was used and when my connection needed to be switched to a different host (@see-other-host@). However, to fully replicate it I needed to have my session data stored from a previous session, which forced Jaxmpp to try to resume XMPP stream. To solve this issue I modified the code so that it will not be possible to log in if Jaxmpp tries to resume a previous session. This is what you described as
This is a very useful feature. When you refresh a page while you are logged in, this our web client will automatically resume previous connection after page reload. I've forced old session data to be removed from Moreover, I've fixed an issue caused by the usage of Jaxmpp 3.2.0-SNAPSHOT instead of 3.1.0, which caused the client to log in just after you pressed @Logout@. I deployed new version at |
|
Andrzej Wójcik wrote:
Yes, this is very useful indeed and from my current tests it looks like we lost this feature as it does not login automatically after page reload. This is not critical for now, but in the future we would like to have it back. Please confirm. |
|
In fact, it works but only for WebSocket connections as there is no Stream Management resumption for BOSH. While I was working on recent issues, I fixed DNS resolution on one of Now as this requests do not time out, they return URL only for BOSH connections as there are no proper TXT entries for our domains. Due to that most likely you are now using BOSH connection and not WebSocket, so it cannot resume stream. We could easily fix it by setting TXT entries for BOSH and WebSocket, ie. for
Most likely we would need to do the same for our other domains. |
|
Thank you for explanation. Created a new ticket for DNS update: #5537 |
Type |
Bug
|
Priority |
Normal
|
Assignee | |
RedmineID |
5529
|
Ok, I have done some more testing.
First of all I discovered under Chrome that websocket is used by default and this problem actually happens with websocket
Under Chrome, I noticed kind of strange behavior, when I logging in, the client stays logged in for a few seconds, then goes back to login screen, then, after another few seconds, it automatically loggings in, without me pressing any button, and then stays logged in for a long time
Then I went back to Safari and the same exact thing happens. I to make sure this is the case with websocket, I manually entered ws connection in advanced settings and i can confirm this happens with websocket
Then, when I reload the page under Safari, it shows an empty login form but after a second it jumps back to the logged in screen
So, to sum it up, it kind of works after all but not entirely the way I would expect.