[10:45:34] i've got a bit of a problem, since yesterday every user i register can not enter the hub, they all get an error of "invalid password" [10:45:52] i also tried myself with the same results [10:46:58] the new accounts appear fine in the users file, but somehow they are not recognized by the hubsoft when the users try to enter [10:47:20] i also restarted the hub, tho the problem persists [10:47:57] please try to make a new account yourself and test it, just in ccase [10:52:59] well well [10:53:41] possibly the same old story why hub owners have got fed up with ADCH++ [10:54:44] oh my, so this is a know bug [10:55:15] not necessarily [10:56:14] it's a way the authentication works, something the devs chosen and often not getting along the way hub owners want [10:56:47] well i just want users to get into the hub [10:57:11] after you regged those new users, did you try the new accounts yourself? [10:57:21] yes, they all failed [10:57:51] don't do that and it will work [10:58:09] https://bugs.launchpad.net/adchpp/+bug/522811 [10:58:41] umm [10:58:58] ok, let me explain a little bit more [10:59:36] i registered a user (i did not use it myself) ... the user told me the password was not recognized, i tried myself... same result [11:00:13] i registered another fresh test account... i tested it, couldn't join, invalid password [11:00:32] yeah delete all those new regs that multiple clients already visited [11:00:37] i registered a third account, same results [11:00:47] ok [11:01:02] create new ones, never try it with your client because it will make it useless for the user [11:01:46] see, you hit all problems why people don't want to use ADCH++ in real world cases [11:02:16] the third one is banning users, which won't work the way you expect because of the same reason [11:03:20] I can create a reg for myself and try but it won't work if I try with this client instance. I will possibly able to do it with another instance. [11:04:52] well, i still fail to see the logic, yesterday, i registered the user and i did not use that account, he was the one and first to use it [11:07:33] see? [11:07:41] I'm in with a different client [11:08:36] umm, i'll test it now, but again ---> yesterday, i registered the user and i did not use that account, he was the one and first to use it [11:08:48] does 'cid' ring any bell for you? [11:10:21] sorry, probably i need some coffee, but i did nothing different from the other registers i did before this [11:10:44] me as OP, i register a user, and pass the information to the user (i do not test the account first) [11:10:48] you did nothing wrong, just expect things working logical while they aren't [11:11:26] so help me understand the logic, because i don't get it [11:13:49] ADC hub identifies logged in users by their CID. CID stands for client ID [11:14:25] If you check the user list (at least in DC++ not sure of other clients) you have to have a column called CID. [11:15:30] yes i'm aware of that [11:16:10] ADCH++ currently uses an authentication scheme that checks for the users' CID first and then ONLY if the CID is not in the registered users database, then looks for the nick. [11:17:19] so basically regs are tied to the client the user is using until the user changes it's client and coming in with a new CID, then it will look up for the nick. [11:17:48] therefore you cannot use multiple registered account with the same client [11:18:05] this is of course a nightmare for a real world private hub owner [11:19:11] since you e.g. cannot test whether a reg is working or not, which is a basic operation in a real world private hub [11:19:55] In ADC's point of view this behavior is logical, it actually streghtens the hub's security [11:21:32] I have tried multiple times to convice the ADCH++ developers to consider adding an option to change this behavior to work like other hubs - in the hub owner's own decision [11:22:02] You see the bug report, my patch was denied. [11:22:07] yes [11:22:40] Also the part of the LUA code was restructured since so there's no such easy way to achive this than before. [11:23:53] ok, so far so good [11:24:05] It is still in my head to do something about it and by now when nobody seem to care of the project among the people who created it, it may very well possible. [11:24:35] but i still fail to see how this applies to what happened yesterday [11:24:41] I'd add this conversation to report if you allow me. [11:24:59] yes sure, no problem about that [11:25:28] but again eMTee, this is no what happened yesterday, in my line of thought at least [11:26:27] yesterday i registered a NEW user, he has not entered the hub before, so he had a NEW CID, i did no test that account, so the account has no CID attached to it [11:26:32] well, it's tricky and can cause unforeseen events. I believe you so let's do it again step by step. [11:26:50] Just remove all new regs and try again. [11:27:35] Do another reg for me yourself and I visit with both existing and yet another client and you'll see. [11:27:39] yes, i just removed them, i downloaded a new AirDC portable, registered a new account, tried and worked [11:28:21] so there you go [11:28:23] this is a new user, it has been tested by a ffresh portable airdc [11:28:23] Nick: Password: Hub address: [11:28:47] so in theory you can not use this account with your client [11:29:27] yes, with those two what is already visited the hub with my two existing accounts [11:29:44] ok [11:30:05] - [11:29] *** Connecting to <>... - [11:29] *** Connected - [11:29] *** Stored password sent... - [11:29] <> Invalid password - [11:29] *** Invalid password [11:30:33] ummmm [11:31:05] ok [11:31:25] the new user i tried to register yesterday is still connected to another hub [11:31:44] if he could not join it means its CID has already been attached to another user [11:31:49] that's right? [11:32:10] no, cid is unique to the client [11:32:17] sure [11:33:32] then i don't know how it failed to join and the whole invalid password thing [11:33:46] (i do understand your explanation and how it works) [11:34:01] but again, yesterday was not the same [11:34:23] as it was a fresh account, nobody used the account, only the user itself [11:34:46] I'm in with [11:34:54] 3rd different client [11:35:10] new cid, that doesn't exists in the reg db [11:35:39] i think i fail myself to explain [11:36:02] the guy who you tried to register might already have a reg in your hub with a different nick [11:36:06] for example [11:36:26] he tries to enter with the new reg but his cid is tied to the old reg [11:36:34] this is one possible explanation [11:36:38] that's what i was trying to expose when [01/06 - 11:31] if he could not join it means its CID has already been attached to another user [11:37:03] -- another user --> another nick [11:37:09] yeah sorry [11:37:09] another user --> another nick [11:37:22] the CID is public i guess [11:37:27] yes [11:37:36] I told you just above how to find it [11:37:42] and its the same on NMDC and ADC (i know on NMDC it is no being used) [11:37:50] no [11:38:18] for NMDC there's a pseudo CID used. the NMDC protocol does not have cid at all. [11:38:36] it's a compatibility kludge [11:39:04] ahh, so the CID that appears in NMDC CID column has no sense [11:39:15] exactly [11:39:30] and it's actually varies hub by hub in NMDC [11:39:48] it is generated from the hub address and the nick used [11:39:57] that's why it is called 'pseudo' [11:40:01] well. um i can try the IPs match [11:40:56] umm, or perhaps this user was an old user, with another nick registered in the hub [11:41:06] yeah most probably [11:41:23] in which case he can still enter if you delete the new reg [11:41:37] it is identified by the cid first [11:41:41] he probably don't remember he was in the hub [11:41:55] nicks can be anything, it's a visible thing only in ADC [11:42:12] you can even have multiple users with the same nick [11:42:14] can i track a user by its IP? [11:42:33] though it can be disabled in the settings, thank god :p [11:44:04] tell the guy to enter temporarily to DCDev public. it is safe, normal users cannot search/download [11:44:31] take not the of the cid and you check your hub db whether it exists [11:44:57] but to avoid the hassle, just delete the new reg and tell the user to try to connect without any reg created [11:45:13] this will tell you if he's already regged by his cid [11:45:29] i tried 3 times yesterday [11:45:44] the problem is if the user uses different password [11:45:55] i deleted his account 3 times, re-registered again, pass him the new accound data, same results [11:46:14] so yeah, make him connect to a public ADC hub, check the cid and remove all regs with that cid [11:46:20] that's the cleanest solution [11:46:44] i'll do that [11:47:13] now think about yourself how lucky you are you can gasp all this insanity [11:47:26] 99.9% of hub owners couldn't [11:47:37] that's why they left ADCH++ for good [11:47:38] but its perfectly logical [11:48:06] sure it's logical but for a real world usage of the hubsoft for running a private hub it's a PITA [11:48:41] this is why it cries for an option to disable this on the hub owners decision [11:49:23] they decide on their own if they want to losen the hub security in favor of easy operation [11:49:33] i do now know why didn't happen to me previously, when i pre-configure clients for another users, i test the fresch clients, not my client, so this problem never occurred before [11:49:58] the developers of ADCH++, however superb minds they are, somehow have never understood this