Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Allow takeover of a MUC nickname if it's by the same account that owns the nickname

Description

With BOSH based implementations, you find yourself left with sessions that "hang around" for a while. In theory browser based apps can just log out, cleaning up the session. However, browsers crash, and the sessions can get "stuck". As a result, you may reconnect and end up having a nickname conflict that you can't get rid of because the old session is still around. What this issue will address is the ability for, if there's a nickname conflict but it's owned by you, allowing you to take over that nickname. (you "kick" the original instance and take it over basically) The original login, if it's a real login, will see a kicked message indicating that they got booted because they logged in from a different location.

Environment

None

Activity

Show:

Pedro Solá November 13, 2013 at 2:28 PM

Correct me if I'm wrong, but it seems to me this functionality goes against the XEP-0045 (7.2.9) Nickname conflict spec.

It states:

If the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource.

If this spec were followed it would resolve the original problem described in this issue.

But the real reason I'm commenting on this is because the current implementation is causing me problems. To describe my setup: I've got a MUC running over BOSH on my website. I'm "pre-initializing" the sessions, to avoid prompting the user for a password. Every time the user opens a new tab, a new session is created, and is kicking the other sessions.

What do you think about the spec? Can you recommend a workaround for me?

Thanks!

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created May 8, 2008 at 10:56 PM
Updated November 13, 2013 at 2:28 PM
Resolved May 9, 2008 at 1:52 AM