Users created via. cyrusauth cloning have the wrong nic #650

New Issue

2026-10-05T04:36:17+02:00

adam commented

2026-10-05 04:36:17 +02:00

With ZNC 1.6.1 I have found that if I enable user creation and cloning with the cyrusauth module the created users get the nick, ident, and realname information from the cloned user not the user logging in. This is true both for the user information and any networks associated with the cloned user.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

With ZNC 1.6.1 I have found that if I enable user creation and cloning with the cyrusauth module the created users get the nick, ident, and realname information from the cloned user not the user logging in. This is true both for the user information and any networks associated with the cloned user. ## <bountysource-plugin> Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/28758045-users-created-via-cyrusauth-cloning-have-the-wrong-nic?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:36:18 +02:00

That would be an interesting feature. Right now real name from client isn't used at all.

That would be an interesting feature. Right now real name from client isn't used at all.

adam commented

2026-10-05 04:36:18 +02:00

Real name would be nice, but the nick from the client goes in as the alternate nick rather than the primary when the user is cloned.

A related issue is that it doesn't pass the password through to the IRC server if it requests authentication, but that's a separate issue from the nick issue. Having to configure the password manually in the network definition is a bit of a pita as well as being a security risk as the password is then in plain-text in the config.

Real name would be nice, but the nick from the client goes in as the alternate nick rather than the primary when the user is cloned. A related issue is that it doesn't pass the password through to the IRC server if it requests authentication, but that's a separate issue from the nick issue. Having to configure the password manually in the network definition is a bit of a pita as well as being a security risk as the password is then in plain-text in the config.

adam commented

2026-10-05 04:36:19 +02:00

This behavior seems to be the default if you manually clone a user as well. The nick/altnick/ident/realname all default to the clone user settings instead of the the new user name. I can't see how this functionality is in anyway a feature and not a bug. With manually cloning you at least have the option to delete these fields so that they default to the default values (the user name). With cyrusauth cloneuser this isn't an option so you get a new user setup but with the wrong values filled in, which makes it essentially useless for an enterprise environment like ours with hundreds of LDAP accounts we'd like to not have to manually maintain in ZNC.

This behavior seems to be the default if you manually clone a user as well. The nick/altnick/ident/realname all default to the clone user settings instead of the the new user name. I can't see how this functionality is in anyway a feature and not a bug. With manually cloning you at least have the option to delete these fields so that they default to the default values (the user name). With cyrusauth cloneuser this isn't an option so you get a new user setup but with the wrong values filled in, which makes it essentially useless for an enterprise environment like ours with hundreds of LDAP accounts we'd like to not have to manually maintain in ZNC.

adam commented

2026-10-05 04:36:20 +02:00

Here is a Perl module that sets user's default nickname, alternative nickname, ident and real name based on user's username:

# ZNC Perl module to set defaults on newly created users.
# Copyright (C) 2016 Vasilis Tsiligiannis <acinonyx@openwrt.gr>

# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

package userdefaults;

use strict;
use warnings;
use base 'ZNC::Module';

sub description {
    "Module to set defaults on newly created users"
}

sub module_types {
    $ZNC::CModInfo::UserModule
}

sub OnLoad {
    my $self = shift;

    if (not $self->ExistsNV("FirstLoad")) {
        $self->GetUser->SetNick($self->GetUser->GetUserName);
        $self->GetUser->SetAltNick($self->GetUser->GetUserName . "_");
        $self->GetUser->SetIdent($self->GetUser->GetUserName);
        $self->GetUser->SetRealName($self->GetUser->GetUserName);
        $self->SetNV("FirstLoad", "yes");
    }

    return 1;
}

1;

Here is a Perl module that sets user's default nickname, alternative nickname, ident and real name based on user's username: ``` perl # ZNC Perl module to set defaults on newly created users. # Copyright (C) 2016 Vasilis Tsiligiannis <acinonyx@openwrt.gr> # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. package userdefaults; use strict; use warnings; use base 'ZNC::Module'; sub description { "Module to set defaults on newly created users" } sub module_types { $ZNC::CModInfo::UserModule } sub OnLoad { my $self = shift; if (not $self->ExistsNV("FirstLoad")) { $self->GetUser->SetNick($self->GetUser->GetUserName); $self->GetUser->SetAltNick($self->GetUser->GetUserName . "_"); $self->GetUser->SetIdent($self->GetUser->GetUserName); $self->GetUser->SetRealName($self->GetUser->GetUserName); $self->SetNV("FirstLoad", "yes"); } return 1; } 1; ```

adam commented

2026-10-05 04:36:20 +02:00

is there any progress on this, upstream?

It'd be nice imho, to use the connecting IRC client's supplied values.

@sjthespian I'd rather not have the same password for IRC channels as my system/company/LDAP/whatever password. an option to do so would be fine, but by no means a desireable default.

is there any progress on this, upstream? It'd be nice imho, to use the connecting IRC client's supplied values. @sjthespian I'd rather not have the same password for IRC channels as my system/company/LDAP/whatever password. an option to do so would be fine, but by no means a desireable default.

adam commented

2026-10-05 04:36:21 +02:00

@ikcalB at the time I wrote this issue, I was supporting an IRC server that used the corporate LDAP as the authentication back-end, so we didn't have a choice about whether or not to use the same password. We were required to do this by our security dept as we had to require "single sign-on" so they could easily disable accounts.

An option would be fine (and I'm long gone from that job, so I don't need this any more anyway... :-) )

@ikcalB at the time I wrote this issue, I was supporting an IRC server that used the corporate LDAP as the authentication back-end, so we didn't have a choice about whether or not to use the same password. We were required to do this by our security dept as we had to require "single sign-on" so they could easily disable accounts. An option would be fine (and I'm long gone from that job, so I don't need this any more anyway... :-) )

adam commented

2026-10-05 04:36:22 +02:00

Hi! Is there possibly any update on this?

Hi! Is there possibly any update on this?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#650