+1 for option 1
More details inlined.
How this change would interact with maibox event serialization and the
event bus?
Regards,
Benoit
On 04/08/2022 10:20, Quan tran hong wrote:
Hi folks,
Recently when I working with the RSpamD module, I found it is hard to
access a message with just a messageId from a system aspect (without a
dedicated username context).
I have a look again at our MailboxSession code and also the same topic
which Rene raised a long time ago (
https://lists.apache.org/thread/chmylvglv3mqnmrgwyg49qwmbc5nxfff), I
realized that our System session type does not have a really different
meaning from normal User session type.
I believe that I am not the only one having this issue until now but this
is an issue that stayed low in our code base with some disadvantages:
- It is hard to implement say curl -XDELETE /msgs/:messageId (without
username context).
- We are not able to distinguish (eg in logs) between user actions and
stuff triggered via a web admin task. Only using users brings in
traceability issues...
So I decided to raise this topic again to solve this issue one and for all.
Here is my idea on how to solve this (get inspiration from Rene's old PR:
https://github.com/linagora/james-project/pull/3038):
- Refactor `createSystemSession` -> `createUserSession` (quickly change
system -> user session in code)
- Create `createSystemSession` which creates a session with a meaningful
System type
Using the exact same naming is confusing.
Also, if I use `createSystemSession` in an extension, then before that
change rights are scoped to the user, after that is unrestricted which
could be a security issue.
I would prefer a `createUnrestrictedSession`.
While speaking about names "System types" does not sound relevant
either. Maybe "component" ?
- Adding tests to make sure System type session have the full right access
to arbitrary user resources (rename mailbox, delete mailbox, create
mailbox, copy message, setFlags, delete message, move message, read
message, search mailbox, search message,...).
The scope of `TypeSession` refactoring is my concern with the following
options:
- Option 1: 2 types of session (User/System): easier to archive our needs.
- Option 2: 4 types of session proposed in the old ML thread
(User/ImpersonatedUser/DelegatedUser/System): more comprehensive and good
for audit actions (by who) but come with bigger refactoring effort
(action's actor information refactoring).
I propose we choose option 1 first to fastly archive our need and spend
more effort with option 2 later.
Here is my proposal on this topic. What do you think? Feedback is welcome
:')
Best regards,
Quan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
