Opened 11 years ago

Last modified 5 years ago

#5086 new defect

no two xmpp accounts with same screenname/domain

Reported by: rjhall Owned by: deryni
Milestone: Patches Needing Improvement Component: XMPP
Version: 2.4.0 Keywords:
Cc: datallah, iRonManNCSU

Description

New to 2.4.0, it is no longer possible to create multiple xmpp accounts where the screenname and the domain are the same. (Using a different resource and/or connect server does still not allow the second account to be created).

The error message seen is: unable to save new account An account already exists with the specified criteria

Attachments (1)

patch_5086.1 (970 bytes) - added by wkeicher 10 years ago.
change jabber_normalize to use resource id when it is available

Download all attachments as: .zip

Change History (53)

comment:1 Changed 11 years ago by deryni

  • Owner changed from nwalp to deryni

Using a second connect server is not a meaningful distinction and will not be supported, using a different resource however is and should be. The problem is with the jabber_normalize function, it normalizes resources away except for chatroom user jids.

comment:2 Changed 11 years ago by eeeldert

I can confirm that the resource part is ignored, and I'm unable to create a second account. This is highly annoying, as I have two accounts with the same screen name and domain, but on different servers, so I can only define one of those two accounts at the same time.

comment:3 follow-up: Changed 11 years ago by deryni

What sort of scenario is this wherein two servers with the same domain are not the same actual server?

comment:4 Changed 11 years ago by eeeldert

Within our organization we have two different IM platforms. However, I need to communicate with users on both systems, so that's where the requirement comes from. As the creator of the ticket indicated, this scenario worked fine before 2.4.0.

comment:5 Changed 11 years ago by rjhall

Another example is if you have a test and User Acceptance and a production system, all sync'd with the same user details. Your screenname and domain are the same, only the connect server information is different.

comment:6 Changed 11 years ago by sannear

This is a real nuisance for me. I have two connections to the same server, one when I am at work (connect direct to jabber server) and one when I am at home (through an ssh tunnel). I can't have both accounts set up at the same time (with different connect servers). Very frustrating

comment:7 follow-up: Changed 11 years ago by deryni

This never "worked fine" it did however not often hit the problems (though they definitely existed).

It is not the case that only the connect server differs between test and production systems as the resource can also differ (and this is a difference which actually *is* meaningful and is something we should support but currently do not).

sannear: As to your direct/ssh tunnel thing, a dynamic hosts entry (set up at interface connection time) set up for a custom connect server (e.g. workserver) which either points to the correct server or points to the ssh tunnel should allow a single account to Just Work correctly when both at home and at work (and doesn't have the issue of duplicating your account data in the accounts.xml, doesn't duplicate the buddy list data in blist.xml, doesn't duplicate buddy icon information, and doesn't split up logs for the "same" account and same buddy over different directories.

I fully intend to see about attempting to figure out a reasonable way to allow handling accounts with differing resources correctly, but I do not know when I will have the time to sit down and investigate it fully enough to work out how to avoid any issues with doing it (I don't even know if there will be any issues offhand). Anyone who wants to step up and start looking into this is welcome to do so, feel free to contact me via xmpp at pidgin.im with any questions.

comment:8 Changed 11 years ago by robinzim

I'm adding a "me too" entry.

From deryni:

This never "worked fine" it did however not often hit the problems (though they definitely existed)

Maybe so, but the previous version did work fine for me. I am in a similar situation where we have two servers at work that use the same username/domain. From my end-user perspective, Pidgin has gone backwards because I can only connect to one of them now.

I see that the priority is set to "minor". But it's not! I would much rather be using Pidgin but now I need to look at alternatives. Please fix this so I can give all my love to Pidgin...

comment:9 in reply to: ↑ 3 ; follow-up: Changed 11 years ago by chemistrydioxide

Replying to deryni:

What sort of scenario is this wherein two servers with the same domain are not the same actual server?

I actually don't see why you're running two INDEPENDENT Jabber servers on the same domain.

If you need two IM platforms, you should use two different domains. Then you could enable S2S on both servers and users would no longer need to connect to both servers.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 11 years ago by robinzim

Replying to chemistrydioxide:

I actually don't see why you're running two INDEPENDENT Jabber servers on the same domain.

Ah, if only I had control I would do the sane thing. But I work for a huge company (70,000+ employees) and, alas, the people who run the IT infrastructure are a closely guarded secret, protected by an impenetrable maze of bureaucracy and incompetence. Who can say why they set things up this way? The IT department moves in mysterious ways...

We do have a single sign-on username/password that we can use in all environments so perhaps that's the driver. The upshot is is that's the environment I have to work in -- and the previous version of Pidgin did it just fine. Maybe internally it had some issues, but as far as I was concerned, it worked.

I'm no software engineer (well, actually I am) and I don't know much about how the internals of these servers work (that's true, I don't really know what a domain means in this context, or what S2S is) but it seems to me that the server connection is one of the things that differentiates users, not just the username and domain.

And, again, I say that in complete ignorance of how the internals if IM actually work.

I would much rather use Pidgin over any other client, therefore I'm lobbying for this fix so I can keep using my favourite IM client.

comment:11 Changed 11 years ago by deryni

Ignore the priority field, it doesn't mean what you think it means.

I would like to support differentiating accounts by resource, however that is not an assumption that has heretofore been made by the pidgin core and UI and the danger is that any such differentiating change will either require somewhat invasive changes to a number of places and/or that such changes will either not be made or not all be made and that rather complicated, confusing, and unfortunate bugs will occur as a result.

I regret that I don't have anything more useful to say about this or the time to sit down and start working on this to see just how bad the changes necessary would be (they may be better than I fear, though I'm not hopeful about that).

comment:12 in reply to: ↑ 10 Changed 11 years ago by chemistrydioxide

Replying to robinzim:

I'm no software engineer (well, actually I am) and I don't know much about how the internals of these servers work (that's true, I don't really know what a domain means in this context, or what S2S is) but it seems to me that the server connection is one of the things that differentiates users, not just the username and domain.

A Jabber ID consists of 3 parts (a username, a domain and a resource; resource and username are optional) and it looks like this: user@…/resource (identifies a client connected to a server) user@… (identifies an account) example.com (identifies a server) example.com/resource (very rare)

In this context, a domain is the part of the Jabber ID that is between the @ and the /.

S2S (Server-to-Server) is a part of the Jabber protocol that allows users who are on one server to talk to users who are on another server. If you want to use S2S the admin just needs to set it up on the server and (in some cases) create a DNS record. S2S works between all S2S-enabled servers; It is not neccessary to configure each possible S2S link manually.

S2S requires the domains that are part of JIDs to be unique because they are used to identify the server.

comment:13 Changed 11 years ago by gilbode

I've got the same problem, 2 IM servers same username/domain. But I found a workaround. Create the second account with a different domain name. The account gets created but you can't connect since the domain is incorrect. Then edit the account to the correct (duplicate) domain and you're back to the pre 2.4.0 behavior.

comment:14 Changed 11 years ago by robinzim

I had already tried that. But when I quit Pidgin and restart it, it has purged the second account. So it still seems to validate it. Thanks anyway, though.

comment:15 in reply to: ↑ 7 Changed 11 years ago by dbs

I also have this same situation with 2.4.3 and now am facing switching to a different client.

While waiting on a fix, is it possible to restore the older behavior to allow the multiple accounts with differing resources, and simply warn the user?

comment:16 Changed 10 years ago by deryni

Ticket #5588 has been marked as a duplicate of this ticket.

comment:17 Changed 10 years ago by eloland

Hi Using Pidgin with great enthusiasm because its a sublime communicator, but facing the same problem with duplicate accounts.

To echo the above needs ... could it be possible to diversify on not only user name and domain but also on connect server ? Or Resource ? Or both ? I dont know the technical implications, but can say that after upgrading to 2.5.1 (from 2.3) this stopped working. I could live with a quick fix that may or may not have some issues ... I didnt experience any before.

comment:18 Changed 10 years ago by deryni

As stated, I would like to allow resources to be differentiating details but the internal implications of this are not yet assessed. I welcome anyone who wants to attempt to figure out exactly what will be involved in this change and exactly what issues may arise, at this point I don't even know if this will be a small or a large undertaking (though I lean heavily towards believing it to be large).

Connect server is not going to become an important detail. The only workaround for this would be to find the code that changed which now detects duplicates and disable it, but there were real issues with having duplicates so disabling that code is not without risk.

comment:19 Changed 10 years ago by datallah

Ticket #7169 has been marked as a duplicate of this ticket.

comment:20 Changed 10 years ago by kisree

It is possible with a small trick. I tried in pidgin 2.5.1 and its working.

Steps:

  1. Add the first account in the usual manner.
  1. while adding the second account prefix the account name with " "(space) character. Example: If the account name is "first.last" then give " first.last".
  1. Do the remaining steps to complete the configuration.
  1. while logging in the application will throw error saying "Invalid account name" now remove the space and enjoy both account in the same Pidgin.

Thanks and Regards, Kishore R.

Changed 10 years ago by wkeicher

change jabber_normalize to use resource id when it is available

comment:21 Changed 10 years ago by wkeicher

I'm not entirely sure of all the implications of my patch, but it seems to work so far...

Perhaps someone with more XMPP knowledge can comment on it.

comment:22 Changed 10 years ago by robinzim

I just tried it and it's working! Wow, such a relief. I'll see how it goes over the next few days as I use it in earnest but so far it's good. Thank you very much!

comment:23 Changed 10 years ago by wkeicher

Occasionally I've observed the following problem with the patch...

-initiate chat from buddy list by double clicking name@domain to open new chat window -send message -receive chat from same buddy, and a new chat window is created from name@domain/resource

my guess is message.c handle_chat might need to be tweaked. Another avenue to pursue is to change the if condition in jabber_normalize to look something like this:

if(node && jid->resource && (js == NULL || jabber_chat_find(js, node, domain)))

comment:24 Changed 10 years ago by robinzim

I'll have to take back my elation, I'm afraid. It worked great after I added both servers within that same Pidgin session. But when I closed the app and re-launched it, one of the servers was gone. Even worse, the one that remained was a strange mixture of both. It had the basic settings of one server, and the server connection info of the other.

comment:25 follow-up: Changed 10 years ago by deryni

It is exactly those sorts of confusions and complications that I was referring to when I said "internal implications" that needed to be "assessed". The problem is that the normalize function is currently used for too many things for a change as simple as this to be the entire solution. I think a proper solution would involve including context to the normalization function (to differentiate at least between account names, buddy names, chat rooms, etc.) but I'm unsure what exact differentiations would be needed.

comment:26 in reply to: ↑ 25 ; follow-up: Changed 10 years ago by msngr

Replying to deryni:

It is exactly those sorts of confusions and complications that I was referring to when I said "internal implications" that needed to be "assessed". The problem is that the normalize function is currently used for too many things for a change as simple as this to be the entire solution. I think a proper solution would involve including context to the normalization function (to differentiate at least between account names, buddy names, chat rooms, etc.) but I'm unsure what exact differentiations would be needed.

I agree that the changes look more than trivial. However, this "feature" needs to be disabled. There are genuine use cases for this.

As a workaround, folks that want this feature can try this. This is tested on the latest 2.5.4 version.

Say username is pidgin Say domain is a.com Say connect server is (1) connect.com and (2) other.com

  1. Add an account for "pidgin" as usual for connect server "connect.com"
  2. Add another account but this time give the username something else (say, pidgin1) and specify connect server as "other.com". The account will be added but won't connect (expected as the user name is incorrect) and will be disabled.
  3. Click on "Modify Account"
  4. Now change back the username from "pidgin1" to "pidgin" (the correct username)
  5. Save and re-enable the account

Voila! It connects and you have the same feature set as pre-2.4.0 pidgin. Some code path still allows you to do this (glad that the backend is intact!) Enjoy!

comment:27 in reply to: ↑ 26 Changed 10 years ago by TopDog

Replying to msngr: I think what you will find however as mentioned earlier already is that when you exit and restart the pidgin client the second account is automatically removed and the account you are left with looks like some sort of merged version.. so you would need to do this reconfiguration everytime you restart the client.

comment:28 Changed 10 years ago by deryni

msngr: I'm curious what the 'genuine use cases for this' feature are, would you mind explaining? I've already commented that the only case I can really imagine for needing to differentiate based on connect server is in server deployment testing, a case which I fully understand but feel is simply not compelling in and of itself. It is worth noting that resource differentiation would allow different connect servers as well.

comment:29 Changed 10 years ago by TopDog

deryni, let me try and explain my scenario. Like others I am in the same boat. I am OK on Pidgin 2.3.1 because I guess we are able to take advantage of what is perceived as a "bug" where we are able to define two XMPP accounts using the same "screen name" and "domain" but difference resource names as follows:

XMPP Account 1 Protocol: XMPP Screen Name: john.smith Domain: example.com Resource: Old Connect server: old_server.example.com

XMPP Account 2 Protocol: XMPP Screen Name: john.smith Domain: example.com Resource: new Connect server: new_server.example.com

This configuration works fine in 2.3.1

From 2.4.0 onwards (I have also tried 2.5.1 and 2.5.4) the above configuration is not accepted anymore. Instead the Pidgin client states that you already have an existing account with this screen name already. You seem to mention in your previous post that if you have different resource names it should be fine but this doesn't seem to be the case.

I am at a large enterprise where they are migrating from one XMPP system to another. During this migration period (which has now been 5/6 months and could be another 5/6 months) we are required to be logged into both XMPP accounts to ensure we have full visibility to everyone on the old and new servers. Because of this limitation in the client we can't move past 2.3.1.

As stated already while the Pidgin client is running there is a way to "trick" the account configuration into setting up and connecting to both XMPP servers using the same screen name (and all seems fine). However as soon as you quit and restart the Pidgin client it removes the second account you had setup. Hope that gives a clearer picture :)

comment:30 Changed 10 years ago by deryni

What I said was the desired feature of allowing different resources to indicate different accounts (and thus be allowed) would fix the need for allowing different connect servers to differentiate accounts. That is I would like it if resources were taken into consideration when looking for duplicate accounts but *do not* want connect servers to be taken into account.

Having multiple accounts with the same username and domain is not something we consider a bug, the fact that pidgin cannot tell the two accounts apart is the bug. And it is that bug that we are working around by preventing people from creating duplicate accounts (based solely on username and domain).

Why is your enterprise migrating servers like that? What benefit do they gain from this over simply turning off the old server and turning on the new one? With the appropriate DNS (SRV or otherwise) records this would be transparent to everyone.

It is unfortunate that you are stuck at the moment but as I have repeatedly saidfixing this problem is not at all trivial.

comment:31 Changed 10 years ago by msngr

Replying to TopDog?:

Agreed. You would need to re-configure it for each re-start. But at least for me, I don't reboot my desktop that often -- may be once in a few months. I can live with the hassle of re-configuration :-)

Replying to deryni:

The use-case I was referring to was exactly the same as what TopDog? mentioned above -- that of "rolling upgrades" of servers where in you need to be connected to both servers at the same time during the duration of the migration.

I agree that this may be a non-trivial issue to "fix" but given the fact that 2.3.1 worked fine, it should be possible to identify the diffs between 2.3.1 and 2.4.0 in the relevant modules and go from there; and IF the changes are localized, it should be possible to rollback the specific changes that caused this "breakage". In any case, I will work on this when I have the cycles.

comment:32 Changed 10 years ago by msngr

Just to add one more point: The backend in 2.5.4 seems to support this model as well -- as is witnessed by the workaround I posted. Given the fact that I don't have much familiarity with the code, let me make a bold surmise that fixing the "load accounts" path during re-start should fix this issue -- possibly in conjunction with wkeicher's patch above.

comment:33 follow-up: Changed 10 years ago by datallah

The problem with the "solution" is that it just masks the underlying problem (which is that internally libpurple can't distinguish the two accounts).

The real solution (as deryni mentioned several times) is to update the xmpp prpl so that the resource can be used to distinguish accounts with the same bare JID.

comment:34 in reply to: ↑ 33 ; follow-up: Changed 10 years ago by msngr

Replying to datallah:

The problem with the "solution" is that it just masks the underlying problem (which > is that internally libpurple can't distinguish the two accounts).

So, how did it work in 2.3.1?

comment:35 in reply to: ↑ 34 Changed 10 years ago by datallah

Replying to msngr:

So, how did it work in 2.3.1?

It didn't work without side effects. (in fact, according to the commit log, it shouldn't have worked as of 2.2.0)

#2269 was the ticket that prompted the fix.

One of the side effects is that you can't tell which account stuff like buddies/chats are associated with.

comment:36 follow-up: Changed 10 years ago by datallah

We should try something like the patch in comment 23 after we release the next version.

comment:37 in reply to: ↑ 36 Changed 10 years ago by wkeicher

Replying to datallah:

We should try something like the patch in comment 23 after we release the next version.

Not sure if this info helps at all, but I've been successfully using a build of 2.5.2 with the patch from comment 23 for the past month and a half with no apparent issues. Granted I'm not an xmpp chat power user -- I just use it for basic chat in a similar IT environment that has been described in previous comments.

comment:38 Changed 10 years ago by datallah

Just to follow up, the patch in comment:23 isn't going to be acceptable because it creates a scenario where you can't distinguish accounts that are actually online (e.g. for a external "xmpp://" URI request).

comment:39 Changed 10 years ago by TerryZhou

Any workable patches for this issue of 2.5.5? Thanks.

comment:40 Changed 10 years ago by deryni

Ticket #9366 has been marked as a duplicate of this ticket.

comment:41 Changed 10 years ago by rekkanoryo

Ticket #9375 has been marked as a duplicate of this ticket.

comment:42 Changed 10 years ago by bernmeister

Perhaps move this to Patches Welcome...

comment:43 Changed 10 years ago by darkrain42

  • Milestone set to Patches Needing Improvement

I agree with deryni's statement in comment 25 (that would also fix some other XMPP-related normalization issues).

comment:44 Changed 9 years ago by darkrain42

Ticket #10168 has been marked as a duplicate of this ticket.

comment:45 Changed 8 years ago by rekkanoryo

Ticket #13565 has been marked as a duplicate of this ticket.

comment:46 Changed 8 years ago by hobarrera

Issue persists as of 2.7.11, can't create two account with distinct username+domain+resource, I'm prompted they're the same.

Any idea when this will be fixed? I've only ever used a single account, but now, I need to use a second resource, and I can't. It's a real-world scenario really, and just one domain+one server.

comment:47 Changed 6 years ago by datallah

Ticket #15562 has been marked as a duplicate of this ticket.

comment:48 Changed 6 years ago by datallah

Ticket #15637 has been marked as a duplicate of this ticket.

comment:49 Changed 5 years ago by hroncok

This bug also prevents to create Google Talk and XMPP account with the same JID. Now when Google closed s2s connection, I need to connect both to GTalk and my new Jabber server, so I stay in touch with both Google and non-Google users.

comment:50 Changed 5 years ago by dustin

A workaround for this may be to use a Jabber-to-Jabber transport (never tried a case like this, though).

This would imply using a different XMPP account and logging into your old XMPP account (or maybe the GoogleTalk? account) via a j2j gateway service.

That service would act as a relay, forwarding messages between your old and new XMPP account, but Pidgin would be using the gateway's name (I think).

There's a security disavantage to this, because the relay knows your account password and sees all your contacts and messages. So it's ideal if j2j and the new account are also on your XMPP server.

(In Pidgin, you need to activate the XMPP Service Discovery plugin for that.)

Last edited 5 years ago by dustin (previous) (diff)

comment:51 Changed 5 years ago by iRonManNCSU

Also having problems with this using an enterprise Google account, and an internal XMPP server using the same username.

comment:52 Changed 5 years ago by Sevenix

This is quite anoying and prevents me from connecting to 2 of my XMPP accounts just because they happen to share the same username.

Hoping this can get a small BUMP for the next release.

Last edited 5 years ago by Sevenix (previous) (diff)
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!