On Oct 22, 2004, at 12:24 AM, Victor Fariña wrote: Well, the first problem I see is that it doesn't work -- anyone can simply click "edit" and remove the tags again. If it did work, then anyone with general edit permissions could lock any page to be inaccessible to other users just by putting in a random username/group, creating a denial of service attack vector. A parser extension is really the wrong place to be adding security hooks. It won't even get called in the places where it matters, and it's too easy to stuff in fake data or get around it. You should probably be looking at Title::userCanEdit() and Title::userCanRead(), and the protect/unprotect functions. Currently these have a few hard-coded hacks instead of the general-purpose user group system that could be done but that there's been no sufficient interest in to write. -- brion vibber (brion @ pobox.com)

On Fri, 22 Oct 2004 17:20:33 +0200, Ashar Voultoiz <hashar(a)altern.org> wrote: [...] This sounds like a good, solid approach. One thing that might be worth considering (you may not want to code it fully straight away, but maybe bear it in mind while designing the architecture, so that it's feasible) is defining relationships between groups. e.g.: * inheritance: Define permissions["Sysop"] = permissions["Logged in user"] + delete, undelete, protect, ... ** no need to explicitly change rights of all groups if you change the rights of a more general group; e.g. adding a globally usable Special: page shouldn't require changes to the permissions for group "Sysop" as well as group "Logged in user" ** another way of looking at this is: "Sysop" implies "Logged in user" * cumulative: Define permissions["Sysop"] = delete, undelete, protect ** leave the wiki-organiser to assume that all users with "Sysop" status will also have "Logged in user" status in order to do the more mundane tasks ** this is the easier way to go, and is useful anyway for things like permissions["trusted SQL-savvy user"]="Special:AskSQL" which shouldn't imply any other rights, just be added to them I hope this message isn't too waffly, and you get the general drift of what I'm on about. Like I say, these are mainly just eventual aims to keep in mind since you're essentially designing from scratch, rather than immediate to-do items. -- Rowan Collins BSc [IMSoP]

Actually, I think this is probably like my "cumulative" approach, I just didn't explain it very well; what I meant is that if a user is assigned to two groups, they will gain both sets of rights: * User:A has group "Sysop" -> permission(read, write, delete) * User:B has groups "Sysop", "Bureaucrat" -> permission(read, write, delete) + permission(makesysop) Or do you mean that a bureaucrat would actually need to log out and then log in with a different account which could make sysops but not edit pages? By the way, any chance that while we're redesigning we can be consistent with terminology and get rid of this "An Administrator is someone with Sysop status" nonsense in favour of just calling the status flag "Admin"? [I know, this isn't as uncontroversial as I'm making out, it's just a personal bug-bear] Agreed. -- Rowan Collins BSc [IMSoP]