ACL Design

[pjz]

ACLs need to be designed. So far the only ACL we have is global, and works like this:

• Editing pages that start with __ (double underscore, aka 'dunder'`) requires that you are an 'admin'
• You are consider an admin if username be listed in the __admin__ page, or the __admin__ page is empty

Which isn't exactly fine grained, nor user centric. So, some questions:

• An ACL is a list of users/group:permission pairs
  • what permissions do we support?
  • Moin has: read/write/delete/revert/admin
• ACLs are associated with rooms. Are they part of the versioned wiki content of the room, or separate from it? (Data point(s): Moin 1.x has it as part of the wiki page, but 2.x seems to have moved it out into its own thing)
  • Conflating them gets you free versioning, but also means users who can edit the page can also edit the ACL
• How will group definitions work? presuming we support groups, which seems reasonable.
  • I like the usernames-in-a-page thing. Maybe make _group_ special, so /_group_/<groupname> is a group definition. Editable by ?? first entry on the page? Groups can include groups (watch out for loops), thus making it fully general.

[pjz]

_group_ is not particularly humane. /group/<groupname> is fine.

Rooms are fully versioned, so their metadata is/should be too.

Use a meta key on the Room object. Then we can use meteor-autoform as an editor.

[pjz]

URL for metadata? /room/<roomname>/meta ? /meta/<roomname> ? ?section=meta ?

[jbone]

I like the first.

A “thing” (room…?) should have a list of owners. It can be a mixed list of users and groups. An owner can edit metadata. Thoughts?

jb

On Sep 30, 2015, at 11:07 AM, Paul Jimenez notifications@github.com wrote:

URL for metadata? /room//meta ? /meta/ ? ?section=meta ?

— Reply to this email directly or view it on GitHub.

[pjz]

/room/<roomname>/meta is fine, though it precludes later allowing slashes into room names (which may be fine, just something to be aware of).

I agree that permissions should be applicable to a mixed list of users and groups. I'm not sure a simple 'owner' permission model is enough, though. There's now two pieces: the room and the metadata. If the room is the fundamental unit, then there's read/write/delete/revert on the room. Metadata then would also have read/write perms.

Maybe:

meta: {
    perms: {
        room: [ "All:read", "authors:write", "janitors:write,delete,revert" ],
        meta: [ "admins,PJ:read,write", "auditors:read" ]
    }
}

[pjz]

Autoforms look kind of heavyweight, as they require attaching a schema to an entire Collection. json-editor looks a lot more adaptable.

[pjz]

Metadata editing works as of https://github.com/grupoarc/grouphug/commit/946983508c7b643338d91fb00ed578360387ec07

[pjz]

Parts left to do:

• [ ] groups - /groups/<groupname> - lists of users/groups. Editable by first entry on the page. or do they get their own metadata? ick.
• [ ] ACL parsing/checking - given an ACL definition and a username, figure out whether they can or cannot read/write/etc a page.

[pjz]

Does /groups/* have history?

[pjz]

As discussed, /groups/groupname will be a shortcut (internal 'redirect') for /room/__group__groupname, that will provide easier access.