Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

um_callerid, um_regonlymsg: various cleanups #364

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

um_callerid, um_regonlymsg: various cleanups #364

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
20502fc
um_callerid, um_regonlymsg: use allow_message for reverse auto-/accept
dwfreed Aug 23, 2022
d27fba3
um_regonlymsg: check source identified before scanning /accept list
dwfreed Aug 23, 2022
529aef6
Merge branch 'main' into dwfreed/callerid-cleanup
dwfreed Nov 9, 2022
72f1ee6
Merge branch 'main' into dwfreed/callerid-cleanup
dwfreed Mar 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 1 addition & 3 deletions modules/um_callerid.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,9 +182,7 @@ add_callerid_accept_for_source(enum message_type msgtype, struct Client *source_
* as a way of griefing. --nenolod
*/
if(msgtype != MESSAGE_TYPE_NOTICE &&
IsSetAnyCallerID(source_p) &&
!accept_message(target_p, source_p) &&
!IsOperGeneral(target_p))
!allow_message(target_p, source_p))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the right test for here - if you message someone who's currently +M then an auto-accept wouldn't be added, and once +M times out they won't be able to reply. The version of this part from #383 takes account of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that if you have +M set, you should be around (and not just letting it time out while AFK), and equally if it gets dropped (because you're busy), you can always reset it. I also imagine the typical use of +M is such that it is set for a split second so a global/server notice can be pushed out and then cleared again. (Eg, I have an alias for OFTC's "god" mode that sets it, does the thing I want to do, and then clears it right after). I really don't think this is going to be much of an issue in practice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the typical usecase is any time staff are attempting to message a user for network-related things and they're +g, in which case the only thing that needs force is your initial messages. if they choose to respond, auto-accept makes sense for a back-and-forth of unpredictable duration

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, so you set +M for your initial message, and then clear it right after, and when the user responds, auto-accept still kicks in with this change, because you are no longer +M

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why clear it when it'll time out all on its own

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because you don't need it anymore and you should be carrying excess privilege for as short a duration as necessary? A simple client alias can handle the whole process for you, eg /alias overridemsg umode +M; msg $0 $1-; umode -M

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels like seeking a problem to justify a solution. i dont think holding on to +M for a few minutes more than you need it is particularly a problem, same with override. real world usage would agree with me

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(especially because you can't foresee how long you'll need the powers)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clogging up (and potentially completely filling) a user's /accept list with auto-accepts that they often don't even know exist isn't a problem? Especially with relaxed caller-id, every person you message, even if they are capable of messaging you because of relaxed caller-id, will earn you an auto-accept that isn't even necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, i don't think that's a problem, or at least don't think +M is anything to do with making that not a problem

{
if(rb_dlink_list_length(&source_p->localClient->allow_list) <
(unsigned long)ConfigFileEntry.max_accept)
Expand Down
8 changes: 3 additions & 5 deletions modules/um_regonlymsg.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,10 +85,10 @@ allow_message(struct Client *source_p, struct Client *target_p)
if (IsOper(source_p))
return true;

if (accept_message(source_p, target_p))
if (source_p->user->suser[0])
return true;

if (source_p->user->suser[0])
if (accept_message(source_p, target_p))
return true;

return false;
Expand All @@ -101,9 +101,7 @@ add_callerid_accept_for_source(enum message_type msgtype, struct Client *source_
return true;

if(msgtype != MESSAGE_TYPE_NOTICE &&
IsSetRegOnlyMsg(source_p) &&
!accept_message(target_p, source_p) &&
!IsOperGeneral(target_p))
!allow_message(target_p, source_p))
{
if(rb_dlink_list_length(&source_p->localClient->allow_list) <
(unsigned long)ConfigFileEntry.max_accept)
Expand Down