Announcement Announcement Module
Collapse
No announcement yet.
Spring ACL 'ace_order' Question Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring ACL 'ace_order' Question

    I'm working with an authorization compatible with Spring ACL, but which doesn't go exclusively through Spring. E.g., data fixes and mass updates are handled directly through the DB. In these situations, we end up inserting new acl_entry rows and are forever mucking around with figuring out the ace_order.

    But the order of the ACL entries is irrelevant to our use cases. Is now and will always be provably irrelevant.

    We'll do our own testing of course, but before diving into it, made sense to ask first, what I'd like to do is just shove '0' into this field.

    a) The same number, like 0, for everything; the default schema imposes constraint 'unique (acl_object_identity, ace_order)', which would be dropped in this scenario. This is the easiest and, so long as Spring can deal with no/random order to the ACL, it's fine.

    When I say "Spring can deal" here, I mean the implementation. I understand that I'm talking about potentially fudging with the design a bit (maybe, the docs aren't

    From Spring Security 3.1 Java API:

    "The order that entries appear in the array is important for methods declared in the MutableAcl interface. Furthermore, some implementations MAY use ordering as part of advanced permission checking."

    This sounds like well ordered sets are not required or guaranteed in general. Unfortunately, the meaning or scope of 'important' isn't clear, or what 'advanced permission checking' is. It kind of sounds like what I want to do might work, though under what conditions is ambiguous.

    FYI, I'm looking for clarification WRT to current implementations. I understand without more precision in the spec, it would not be possible to rely on code necessarily being forward compatible. If we have to rehab the data later, that's fine. It's a big enough issue that it's worth the convenience of ignoring ace_order like we want to now.
Working...
X