Hi Benoit, First of all, thank you for your feedback.
I would prefer a `createUnrestrictedSession`. > While speaking about names "System types" does not sound relevant > either. Maybe "component" ? I agree. How this change would interact with maibox event serialization and the > event bus? Do you mean the case that a component triggers a mailbox event? Is Username.of(component class) good enough to you? Otherwise, we would need to rethink the username/component in maibox event serialization' structure. Regards, Quan Vào Th 5, 4 thg 8, 2022 vào lúc 17:10 Benoit TELLIER <btell...@apache.org> đã viết: > +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 > >
