Правильный способ обновления ACL в Spring ACL

avatar
Colm Bhandal
1 июля 2021 в 17:41
31
0
0

Как правильно обновить существующий ACL с помощью Spring ACL?

All of the code I've found so far like here, here and here relies on the fact that AclImpl, which implements MutableAcl, является единственной реализацией Acl, поэтому общий шаблон, который я вижу, таков: 

acl = (MutableAcl) aclService.readAclById(objectId);

Где у нас есть изменяемая служба ACL следующим образом:

JdbcMutableAclService aclService;

То есть объект Acl просто преобразуется в MutableAcl в предположении, что на самом деле это AclImpl. Оттуда методы MutableAcl можно использовать для обновления и вставки ACE, после чего метод updateAcl updateAcl может обновить списки ACL.

Хорошо, похоже, это работает на практике.

Но прежде чем я напишу свой собственный код, используя этот шаблон, я хотел бы проверить, знает ли кто-нибудь лучший способ сделать это? Мне не очень нравится идея понижать тип, который кажется намеренно оставленным абстрактным.

Кроме того, возможно, кто-то что-то знает о причинах решения архитекторов Spring ACL возвращать только тип Acl, а не тип MutableAcl из readAclById(objectId)? Мне это кажется странным решением, и я не могу его понять. Я между несколькими вариантами:

  1. Это было преднамеренное решение с их стороны: они предполагают, что ACL исправлены после их первоначального создания. Но это не имеет особого смысла. В любом реальном приложении, о котором я могу думать, разрешения должны быть динамически предоставлены/отменены. - В таком случае, я, наверное, просто последую за всеми и сделаю хак понижения.
  2. Это было преднамеренное решение с их стороны: они хотят, чтобы вы использовали какой-то другой способ обновления ACL, например. так что вы неявно сбрасываете кеш. - В этом случае мне очень хотелось бы узнать, как правильно поступить, чтобы в моем коде не было ошибок.
  3. Это было сделано непреднамеренно: возможно, случай динамического обновления существующих списков контроля доступа был просто упущен? - В этом случае, опять же, я бы, вероятно, просто пошел на понижение.

Обновление

Глядя на реализацию JdbcMutableAclService, мы замечаем, что используется разновидность шаблона понижающего приведения:

    // Retrieve the ACL via superclass (ensures cache registration, proper retrieval
    // etc)
    Acl acl = readAclById(objectIdentity);
    Assert.isInstanceOf(MutableAcl.class, acl, "MutableAcl should be been returned");

    return (MutableAcl) acl;

Поскольку этот код является частью самого Spring ACL, похоже, можно использовать шаблон понижения приведения, поэтому я так и сделаю.

Кроме того, я все еще не понимаю, почему был принят этот шаблон. Ясно, что разработчики Spring знают, что возвращаемый тип readAclById должен быть MutableAcl, иначе в приведенном выше коде есть ошибка. Итак, в таком случае, почему бы просто явно не указать тип возвращаемого значения MutableAcl, а не просто Acl? Возможно, это технический долг или, возможно, обратная совместимость; хотя я не могу представить себе случая, когда усиление типа не нарушило бы обратную совместимость.

Источник

Ответы (0)