Hello Quan +1 for option 1 And one user for the System session. I got many case in past that need session for "no one"
On Thu, Aug 4, 2022 at 10:20 AM Quan tran hong <quan.tranhong1...@gmail.com> 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 > - 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 > -- Tung, Tran Van *Phone:* (+84) 35 757 6258 *Skype:* tung.tv202
