I need to limit what users can enter into CC and AdminCC. I cannot have
them entering email addresses for those without logins.
How can I limit or secure this?
Joseph D. Wagner
I need to limit what users can enter into CC and AdminCC. I cannot have
them entering email addresses for those without logins.
What do you mean by “without logins”? The email address needs to
correspond to a user that already exists on the system?
-m
What do you mean by “without logins”? The email address needs
to correspond to a user that already exists on the system?
Yes. Here’s what happened. A privileged user entered an external email address into the CC field, which did not have an account. RT autocreated an account for that person, and it accepted that external email address on the CC field. I need to prevent that.
How can I limit CC and AdminCC to email addresses that already have accounts? Either rejecting the ticket or silently failing to add the CC/AdminCC email address would be acceptable.
Joseph D. Wagner
What do you mean by “without logins”? The email address needs
to correspond to a user that already exists on the system?Yes. Here’s what happened. A privileged user entered an external email address into the CC field, which did not have an account. RT autocreated an account for that person, and it accepted that external email address on the CC field. I need to prevent that.
How can I limit CC and AdminCC to email addresses that already have accounts? Either rejecting the ticket or silently failing to add the CC/AdminCC email address would be acceptable.
Use a callback.
Do you know what those are?
-m
What do you mean by “without logins”? The email address needs
to correspond to a user that already exists on the system?Yes. Here’s what happened. A privileged user entered an external
email address into the CC field, which did not have an account. RT
autocreated an account for that person, and it accepted that external
email address on the CC field. I need to prevent that.How can I limit CC and AdminCC to email addresses that already have
accounts? Either rejecting the ticket or silently failing to add the
CC/AdminCC email address would be acceptable.Use a callback.
Do you know what those are?
Specifically: You can use the BeforeCreate callback to prevent
accidental creation of . It is available in Ticket/Create.html,
SelfService/Create.html, and m/ticket/create. It is NOT available for
the “QuickCreate” widget, so users of that widget could add bogus
Requestors at will. Anyone who can add ad hoc recipients to ticket
updates share the ability to add users to RT, so you may want to find a
callback in the Update pages as well. If controlling user creation by
gatekeeping many different paths of ticket modification seems like a
shoddy approach to you, you are not wrong. In RT’s defense, its
eagerness to add new users whenever it sees a new email address is
rooted in the days before spam from random addresses to random addresses
and via random compromised web applications was a widespread problem.
If you use ExternalAuth, setting AutoCreateNonExternalUsers to 0 seems
to be an option that would block creation of users not in one of your
configured external auth sources, but it may have undesirable
side-effects. If you want random strangers to be able to send your RT
mail that opens new tickets, you are stuck with gatekeeping other paths
to user auto-creation.
What do you mean by “without logins”? The email address needs
to correspond to a user that already exists on the system?Yes. Here’s what happened. A privileged user entered an external email
address into the CC field, which did not have an account. RT autocreated an
account for that person, and it accepted that external email address on the
CC field. I need to prevent that.How can I limit CC and AdminCC to email addresses that already have
accounts? Either rejecting the ticket or silently failing to add the
CC/AdminCC email address would be acceptable.Use a callback.
Do you know what those are?
Specifically: You can use the BeforeCreate callback to prevent accidental
creation of . It is available in Ticket/Create.html,
SelfService/Create.html, and m/ticket/create. It is NOT available for the
“QuickCreate” widget, so users of that widget could add bogus Requestors at
will.
For reference, BestPractical is not averse to accepting patches which
have new callback hooks. It would probably be a one-liner to add a
callback hook to the QuickCreate widget.
-m