DC++ tries to connect/pm through wrong ADC hub

[MikeJJ]

Basically the nmdc problem for which Token was suggested, seems to also happen with ADC.
To reproduce this
1. connect to a ADC hub where downloads is blocked, e.g. DC Dev Public.
2. get someone else to connect to same hub.
3. connect to a ADC hub where downloads aren't blocked.
4. get same person to connect to this.
5. try doing a download / upload to them from the second hub.

It fails because it tries to connect through the first ADC hub where connections are blocked, instead of the one where the connection was initiated from.

Thanks eMTee for helping verify this.

[Jacek Sieka (arnetheduck)]

yes, it's wrong now...round-robin would be better (starting with the hubframe hub if added from hub frame)

[Big Muscle (bigmuscle)]

Same problem doesn't apply for connecting only, but also for private messaging, sending search results and user commands. I think there shouldn't be online user map stored in ClientManager, but it should try to find online user in correct hub. It would save some memory too.

[Szabolcs Molnár (fleet)]

+1

It's for private messaging too, and it's a critical security issue in that manner, so it would be urgent to fix this bug.

** you cannot share sensitive information on "trusted" hubs in pm, since you never can be sure if your pm goes through on your trusted hub or on another one
** you cannot control bots, because they answer on random hubs and take actions on random hubs
** it's an irritating, old bug but noone seems to care

[Big Muscle (bigmuscle)]

i already tried to fix this bug, but without success. Code of this part is too complicated and it would require redesign client and gui part to avoid stability problems.

[Szabolcs Molnár (fleet)]

it's a privacy problem too, so i set it to hight

[Jacek Sieka (arnetheduck)]

Ok, committed a tentative fix for this...the prefered hub won't be saved in the queue though so it's only valid for the first connection attempt...there's also no warning if pm:s go through another hub (ideally one would have a dropdown with a hub url chooser in the pm case)

[Szabolcs Molnár (fleet)]

Sounds good :) (no, not "good".. rather "great" ;)) )

Just a question about PMs.. you wrote that "there's also no warning if pms go through another hub".. Theoretically how can it happen? I mean when you open a private message window, the PMs in it goes through the initial hub, right? I think if the connection is closed with the original hub, it can go through another one even if the client reconnecs, right? - Maybe this case dc++ could enter a line to the pm window telling the user that the connection with the preferred hub is lost, they have x more hub in common and those will be used for pming. DC++ don't have to track it anymore, but the user will know that it's not ensured that their pm goes through the original hub. If the sender now wants to ensure what hub is used, he may close and reopen the PM window. But you're right, a drop-down list would be better. Just playing with my thougts.

[poy (poy)]

would be nice to only see the nick/hub the PM is going on with, not all of the nicks, in the title bar.

[Big Muscle (bigmuscle)]

I'm not sure about situation when adding ADC source from search result. Since it doesn't know the user's hub, the "hubHint" variable will contain list of all hubs where the user is connected to. What will happen then?

[Big Muscle (bigmuscle)]

Also, I think there's a bug in ClientManager.cpp, function findOnlineUser.

there's: if(u->getClient().getAddress() == hintUrl) {
but it should be if(u->getClient().getHubUrl() == hintUrl) {

because hintUrl is usually set to hubUrl and not to address.

[endator (endator)]

This bug has been marked high since almost a year now, has there been ANY progress?

I still can not get a filelist or download from someone if we both are also in a ADC hub where downloading is blocked (like dcdev). This is starting to feel a little silly to have to close one hub to be able to download off another.

[poy (poy)]

rev 1864 introduces favorite hub groups; PMs & connections with users in hubs that are part of private fav hub groups should now always happen with the correct hub, and won't happen if that hub is offline.
possibly fixed other issues related to this, and added saving of queue hub hints.

haven't tested much of it.

[Steven Sheehy (steven-sheehy)]

This bug is already fixed by someone, why are you assigning it to yourself?

[Toast (swetoast-deactivatedaccount)]

Reverted

mb.team dont mess around here this isnt your playground !!

[Olorin (vivliofika)]

ha-ha-ha!

Hi!
That's great!
People, don't you know about mailing lists?

[Szabolcs Molnár (fleet)]

See priv discussion.

[poy (poy)]

Fixed in version 0.760

[poy (poy)]

the private hub group deal may be removed in the future. re-opening this bug for now.

[Big Muscle (bigmuscle)]

I would insist on fixing this bug completely - introduce hubhint in search results (probably via token) + solve the situation when file with different hubhint is being requested but old connection is used (so connection is made via invalid hub).