Open taggart opened 5 months ago
Thinking about this more...
Does sympa have any policy about scenari changes? Looking at the default scenari it seems they don't change very often, so maybe it has not come up much?
If sympa were to decide to start requiring auth for things like add/del/invite, what would the potential migration look like?
If users provide their own version of a scenari in the etc/scenari
directory with an identical name, sympa will prefer that version over the default/scenari
version. So I can think of a couple ways this could be handled:
Using invite.owner
as an example, if we add the auth requirement to the existing file:
default/scenari/invite.owner
and new behavioretc/scenari/invite.owner
file were relying on the existing default and upon upgrade would get the new behavior (which is good, but might surprise them)etc/scenari/invite.owner
file got whatever behavior that custom version specified and would continue to get that custom behavior after upgrade.etc/scenari/invite.owner
and issue an extra warning that the default changed and they may want to review the changes and update their custom version.In the case, for our example invite.owner
with auth, we would create a new file named something like invite.ownerauth
.
create_list_templates
that should use this new default could be adjusted to use that new typeinvite.owner
would be removed from default/scenari/
and no longer installed on new installs or upgrades (but if it is already there it should remain for existing lists that reference it, assuming upgrading in place and the upgrade process leaves it CHECK THIS) invite.ownerauth
have it available as an option for lists (subject to edit_list.conf
restrictions)invite.owner
if it's being deprecated by upstreamdefault/scenari
invite.owner
and invite.ownerauth
available, existing lists could continue to use the old one or switchetc/scenari/invite.owner
that would continue to work as expectedetc/scenari/invite.ownerauth
already, but I suppose the installer should check for thatThis is all using my example for invite, but probably you can tell I am trying to think about this generically because I think it's probably time that sympa move away from some of this older scenari behavior that is now a problem. In particular many of the public
scenari should no longer be options on new installs and need a migration path for existing installs. So sorry if this is an abuse of the issue tracker, free free to make it a separate issue or move it some place else. Thanks
I +1 to add invite.ownerauth
.
Having too many scenarios is troubling. I think it is a flaw in the current design that we have to have as many options as there are all possible conditions, but we have to live with this for the time being.
I would like to have a version of the "invite" scenari for owner but with authentication. Currently "invite.owner" could be abused by someone forging mail from the owner address, and having an auth version would prevent this.
It could maybe be argued that "invite.owner" should require auth by default. I think that is probably a good idea, but that may come as a surprise to users not expecting it (and automation/form processing people may have written taking advantage of it). Also depending on naming some migration might be required between releases. There may also be use cases where this auth is not required and just adds extra steps (non-public email systems?)
We have the examples of {add,del}.owner vs {add,del}.auth, but also send.owner vs send.ownerauth to use as reference. I think this new scenari could be named either "invite.auth" or "invite.ownerauth", I guess I would lean toward the former. Based on the others, here is probably what it should look like:
(I left "perform" like it is in invite.owner, but they could both be changed to "performed"). Let me know what you think of this, or if I can help in any way. Thanks!