Project

General

Profile

Bug #5529

Avatar?id=6023&size=22x22

Issues with authentication

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:

Description

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.


Related issues

Copied from Tigase.IM Web Client - Feature #5318: In-band registration to use XMPP Data Forms XEP-0004 with captchaClosed2017-05-15

Associated revisions

Revision 7a39f2b5 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

#5529: fixed handling of see-other-host in ConnectionManager for GWT

Revision c5771bf2 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

#5529: improved stream resumption and authentication

History

#1 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

  • Copied from Feature #5318: In-band registration to use XMPP Data Forms XEP-0004 with captcha added

#2 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

  • Status changed from New to In QA
  • Assignee changed from Andrzej Wójcik to Artur Hefczyc
  • % Done changed from 0 to 100

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

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

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 SessionStore when the timeout of stream resumption is reached.

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 sure.im cluster and I think this should fix issues you mentioned. At least I was able to replicate few issues and find out that usage of a newer version of Jaxmpp is a cause of them.

#3 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam over 1 year ago

  • Status changed from In QA to Feedback
  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

Andrzej Wójcik wrote:

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

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.

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.

#4 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

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 sure.im servers, as it timed out, leading to timeout of requests send to our web DNS resolver module. This caused our web client to be unable to resolve TXT DNS entries of sure.im servers and forced it to use ws://sure.im:5290/ as a fallback.

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 sure.im we could use:

_xmppconnect    IN  TXT "_xmpp-client-websocket=ws://sure.im:5290/"
_xmppconnect    IN  TXT "_xmpp-client-xbosh=http://sure.im:5280/"

Most likely we would need to do the same for our other domains.

#5 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

#6 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam over 1 year ago

Thank you for explanation. Created a new ticket for DNS update: #5537

#8 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam over 1 year ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF