james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: ACL Support - cont. from server-user
Date Fri, 06 Jan 2012 17:34:07 GMT
As a side note, we are moving IMAP code from

https://svn.apache.org/repos/asf/james/imap/trunk/
to
https://svn.apache.org/repos/asf/james/protocols/trunk/imap/

I would be better that you code in the latter.

Thx,
Eric


On 06/01/12 12:25, Jochen Gazda wrote:
> Gentlemen,
>
> Please read and comment.
>
> I have started to implement the ACL support. In the very first phase I
> would like to
>   - add support for IMAP GETACL command and
>   - add support for storing ACL at least for one storage backend.
>
> During this first phase I would like to learn how to do things in a
> James-compiliant way so that I will be able to implement other ACL
> commands later.
>
> 1. A new interface org.apache.james.mailbox.MailboxACL and default
> implementation org.apache.james.mailbox.store.SimpleMailboxACL
> Stores an ACL applicable to a mailbox. Inspired by RFC4314 IMAP4
> Access Control List (ACL) Extension.
> Note: An ACL class that could serve our purpose exists in
> com.sun.mail.imap. We will not stick to a proprietary API, will we?
>
> 2. MailboxACL usage:
> org.apache.james.mailbox.store.mail.model.Mailbox<Id>  and
> implementations will be extended to store the related ACL:
>      MailboxACL getACL();
>      void setACL(MailboxACL acl);
> This is probably OK.
>
> 3. MailboxACL usage: org.apache.james.mailbox.MessageManager.MetaData
> will be extended to offer a read access to the ACL of the related
> mailbox. This was approved by Norman Maurer.
>          MailboxACL getACL();
>
> 4. MailboxACL usage: Under org.apache.james.imap ACL-related requests,
> decoders, responses, encoders and processors will use MailboxACL.
> It is probably OK as there is a lot of org.apache.james.mailbox.*
> usage under org.apache.james.imap.
>
> 5. MailboxACL instantiation: Clearly, there will be (at least) two
> places where MailboxACL will be instantiated:
>    i. In Mailbox implementations when reading ACLs from their backends
>    ii. In org.apache.james.imap decoders when parsing the ACL related
> IMAP requests.
>
> At the moment I have hardcoded a constructor of my default
> implementation on both places. I am asking myself if some kind of
> factory pattern should be used instead.
>
> 6. How to access an ACL stored in a mailbox backend from a subclass of
> org.apache.james.imap.processor.AbstractMailboxProcessor:
> At the moment I have this code to prepare a response for GETACL IMAP command:
>              MessageManager messageManager =
> getMailboxManager().getMailbox(buildFullPath(session, mailboxName),
> mailboxSession);
>              MetaData metaData = messageManager.getMetaData(false,
> mailboxSession, FetchGroup.NO_COUNT);
>
> I have not tested it yet, but principally, it should work. I only
> wonder at two things with that code:
>
>    i.  org.apache.james.mailbox.MailboxManager.getMailbox(MailboxPath,
> MailboxSession)
>        It returns a MessageManager rather than a Mailbox. Should it not
> rather be called getMessageManager?
>
>    ii. org.apache.james.mailbox.MessageManager.getMetaData(boolean,
> MailboxSession, FetchGroup)
>        Javadoc says "Gets current meta data for the mailbox." Why is
> this method in MessageManager and not in MailboxManager?
>
> 7. What and in which order should the GetACLProcessor say after
> sending the ACL response?
>    i.  Should it send also unsolicitedResponses?
>    ii. unsolicitedResponses should be sent before or after okComplete?
>    iii. on MailboxException, we send no() and I wonder what should its
> HumanReadableText say?
>    iv. is the no() sufficient for all exceptions? What if somebody is
> asking for ACL of a folder which
>        (a) does not exist or
>        (b) cannot be looked up by the current user?
>        Isn't taggedBad more suitable for (a) and/or (b)?
>
> Here is what I have now:
>
>      @Override
>      protected void doProcess(GetACLRequest message, ImapSession
> session, String tag, ImapCommand command, Responder responder) {
>          final MailboxManager mailboxManager = getMailboxManager();
>          final MailboxSession mailboxSession =
> ImapSessionUtils.getMailboxSession(session);
>          try {
>              String mailboxName = message.getMailboxName();
>              MessageManager messageManager =
> mailboxManager.getMailbox(buildFullPath(session, mailboxName),
> mailboxSession);
>              MetaData metaData = messageManager.getMetaData(false,
> mailboxSession, FetchGroup.NO_COUNT);
>              ACLResponse aclResponse = new ACLResponse(mailboxName,
> metaData.getACL());
>              responder.respond(aclResponse);
>              okComplete(command, tag, responder);
>              //FIXME should we send unsolicited responses here?
>              //unsolicitedResponses(session, responder, false);
>          } catch (MailboxException e) {
>              // FIXME: be more specific in the human readable text.
>              no(command, tag, responder,
> HumanReadableText.GENERIC_FAILURE_DURING_PROCESSING);
>          }
>      }
>
>
> 8. Interpretation of ACLs:
> To have ACL stored on every mailbox is far from being able to tell if
> the given user can perform the given operation for the given
> mailbox(es when copying/moving).
> A new service responsible for resolving of ACLs is necessary. I
> propose to call it MailboxACLResolver.
> In which package should it be placed? Also in org.apache.james.mailbox?
> Probably every single operation between IMAP and mailbox stores should
> pass through this service. Where in the code should such a permission
> enforcement be placed?
> How should MailboxACLResolver be instantiated?
>
> 9. A new event type: org.apache.james.mailbox.MailboxListener.MailboxACLUpdated
> It is quite clear what it should look like. It is also quite clear to
> me where and how it should be fired.
> But I cannot figure out who should listen to it and what the listener should do.
>
>
> Thanks,
>
> Gazda
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

-- 
eric | http://about.echarles.net | @echarles

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message