Besides the links already posted by Cédrick (you can find a demo image
of an old version there) you can find a summary about the access
control list based security model here:
(monticello repository is invalid, classname prefixes have changed)
so I won't recap the points covered there. Basically it's similar to
Windows/new-school Unix (yes, we are serious, Windows).
Does logging into Seaside automatically give me admin in Pier?
Nope, it gives you the rights of this user. What that is depends, well
on the user.
How do I add other users?
Go to /Management/Users, if you have
the permission an `Add User'
command (Pier term for action) should appear.
Is auth handled on a per-page basis,
Yes. Acutally per
structure. A page is a sturcute, but for example a
file is a structure too.
or is it inhearited so that I can do it on a per-tree basis?
Once a structure is created, it gets a copy of the access rules
(access control items) of its parent, from that point on, they are
independend. So like Lukas. However if you add an access rule to a
structure it's possible to check a box that adds it to all children
(where you have the permission). The same for removing. More
sphisticated tools could be implemented if needed.
I'd want any editor to login
you can do that
want to selectively show content based on who you are
do that too
(so that a nonlogged in person wouldn't even see the edit tools).
That's done. IIRC Lukas does it too
now you shouldnt acces any pages even for viewing them (if yout let
(but the pages remains accessible for viewing if you type the adress.
(Is it normal Lukas ?)
I don't fully understand what you want to know so
visibility in general.
If a user doesn't have the view permission for a structure he does not
see it, not even listed in the tree. If he has the view permission for
a child of a structure he is not allowed to view, then the can view
this child by using a link or tying the url.
If he types the url of a sturcture he is not allowed to see, he will
not see it. The title is rendered though last time I checked.
- the actual model is simple yet powerful and flexible, or at least
this is our illusion
- allows you not only to grant rights, but also to deny them
- fancy stuff:
-- groups can contain groups
-- command sets
-- special groups like `everyone', `everyone who is logged in'
- required commands, so for example moving a structure requires the
add right on the target structure
- complete user interface
- magritte UI (mostly)
- stay logged in with cookies
- optional goodies
-- users can for example have an IM address and their online status
will be shown
- tries to prevent dictionary attacks, after 3 invalid tries to login
you have to wait 5 minutes (configurable)
- green tests
- (probably) doesn't load into latest Pier, I will have to adapt it
(shouldn't be too hard). It had to do some overrides before Lukas
started with his work. They should no longer be neccessary so that it
should work better with future versions
- Didn't integrate into stock Pier as well as I'd like it to be but
that should be better with the latest versions in Pier once I've made
the changes (see above). So if you want to see it in action the best
way is probably to use the demo image (follow the links posted by
- more complex than I'd like it to be, although most complexity is in
Magritte/Seaside and the kernel didn't have to be touched for quite
some time. But there's always a tradeoff between adding features and
- quite uncommon model, works well in theory but not really proved in the field