View Issue Details

IDProjectCategoryView StatusLast Update
0005769unrealircdpublic2020-10-11 09:35
Reporterarmyn Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version5.0.5.1 
Fixed in Version5.0.8-rc1 
Summary0005769: Problem with password and/or ident in the block Allow
DescriptionHere's how to reproduce the bug:
Steps To Reproduce1. Configure this block in unrealircd.conf last after all the other allow:
allow {
    ip "test@*";
    class bots;
    maxperip 2;
    password "test123456";
    options { noident; };

2. On mIRC client, configure your ident on "test" and connect to IRC without entering any password "test123456". You will notice in the connection notice-server the class {clients} when it shouldn't, there should be a prohibit kill message because the password is not set.

3. Then on mIRC, configure your ident on "test" (leave it) and connect to irc with the password: "test123456" and there the access is validated and your class in notice-server will be {bots}. Here its ok.
TagsNo tags attached.
3rd party modules



2020-10-09 22:12

reporter   ~0021793

I can confirm the issue, even without allow::options::noident set.

Below is my allow blocks:

allow {
    ip *;
    class clients;
    maxperip 5;

allow {
    ip <redacyed>;
    class clients;
    maxperip 999;

allow {
    ip <redacted>;
    class clients;
    maxperip 999;
    ipv6-clone-mask 128;

allow {
    ip <redacted>;
    class clients;
    maxperip 3;
    ipv6-clone-mask 128;

allow {
    ip <personal ip>;
    class clients;
    maxperip 5;
    password "some_pass";

I've tested with my personal IP and one of my VPS IPs.

The end result is that the user can connect without specifying a password, without any issues.

The password field in the allow block seems to be ignored?


2020-10-10 08:49

administrator   ~0021794

You mean if the password is not supplied by the client (or wrong password) then it continues to next allow block, right?

That is by design, see the UnrealIRCd 5 release notes:
"When matching allow { } blocks, we now always continue with the next block (if any) if the password did not match or no password was specified. In other words, allow::options::nopasscont is now the default and we behave as if there was a ::wrongpasscont too."


2020-10-10 09:13

reporter   ~0021797

This is a shame, because before it was possible to reserve / make deprive an ident or an ip with mandatory password, and if it failed it was a killer, it was perfect


2020-10-10 15:47

administrator   ~0021798

Last edited: 2020-10-10 15:48

The reason it was changed is that most people who used passworded blocks used it to give people "additional rights" above a standard allow block, usually a higher maxperip. Then, if a user would connect without password he/she would get rejected, which was not what people wanted... it was wanted that the default restrictions were used (eg: maxperip of only 2)

You are using it the other way around, not to add additional rights, but to restrict people, sortof like banning or access control. Which I can understand, it's called "allow block" after all.

We could reintroduce a new option that does the opposite of wrongpasscont/nopasscont, that you have to explicitly set in your passworded allow block. Then you have your functionality back again :)


2020-10-10 16:17

reporter   ~0021799

yes if it is possible to put a "nopasscont" option if it is not too long to do, its good


2020-10-10 18:32

reporter   ~0021800

Or then to create a **deny allow** block?

For me would be fine to have an option like <code>nopassblock</code>.



2020-10-11 09:26

administrator   ~0021805

Ok, new option added to reject users that fail to authenticate in such a block. So armyn, for you, see the last example in the commit message below, this will be in 5.0.8:

commit 8619d1e763db030fded8da96f961dbcb8dc985f8 (HEAD -> unreal50, origin/unreal50)
Author: Bram Matthys <>
Date: Sun Oct 11 09:10:21 2020 +0200

    Add optional allow::options::reject-on-auth-failure, as requested
    by armyn in
    The default behavior in 5.x is to continue matching:
    allow { ip *@*; class clients; maxperip 2; }
    allow { ip *@*; password "iwantmore"; class clients; maxperip 10; }
    This so users who provide a password get additional rights,
    such as a higher maxperip or a different class, etc.
    If the user connects without a password then we simply continue
    to the next block and use the general block with only 2 maxperip.
    However, some people want to use passwords to keep other users out.
    That is entirely understandable as it is an 'allow block' after all.
    For example:
    allow { ip *@*; class clients; maxperip 2; }
    allow { ip *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }
    In this case anyone without the correct password will be rejected access.


2020-10-11 09:35

administrator   ~0021806

Last edited: 2020-10-11 09:35

I have also updated the documentation with examples at
Now it should be clear to everyone what to use when... I hope :)

Issue History

Date Modified Username Field Change
2020-10-09 22:02 armyn New Issue
2020-10-09 22:12 PeGaSuS Note Added: 0021793
2020-10-10 08:49 syzop Note Added: 0021794
2020-10-10 09:13 armyn Note Added: 0021797
2020-10-10 15:47 syzop Note Added: 0021798
2020-10-10 15:47 syzop Note Edited: 0021798
2020-10-10 15:48 syzop Note Edited: 0021798
2020-10-10 15:48 syzop Note Edited: 0021798
2020-10-10 15:48 syzop Note Edited: 0021798
2020-10-10 16:17 armyn Note Added: 0021799
2020-10-10 18:32 PeGaSuS Note Added: 0021800
2020-10-11 09:26 syzop Assigned To => syzop
2020-10-11 09:26 syzop Status new => resolved
2020-10-11 09:26 syzop Resolution open => fixed
2020-10-11 09:26 syzop Fixed in Version => 5.0.8-rc1
2020-10-11 09:26 syzop Note Added: 0021805
2020-10-11 09:35 syzop Note Added: 0021806
2020-10-11 09:35 syzop Note Edited: 0021806