Camp Smalltalk results

[stéphane ducasse]

>> For the security issues we have an extension of Lukas original model
>> (or UI based on the original model of lukas). You can find the master
>> report of David  Vogel on http://kilana.unibe.ch:9090/smallwiki/.
>> Now the problem that we have is that the code is breaking certain 
>> parts
>> of SmallWiki
>> and david is not replying to emails (since I guess that he is getting
>> married).
>> So we know that a UI and a better security model is needed (the idea 
>> of
>> the new version is
>> that a local admin should not be able to grant more rights than he
>> owns, and that a local admin cannot damage other local admins). But
>> right now we are stuck. We will see how/if this is worth to rescue the
>> code of David Vogel or just to reimplement the idea.
>
> We used the "advanced security" system, which I think was David 
> Vogel's.  We
> did not find any bugs we couldn't fix.  If you send a list of things 
> that do
> not work (especially test cases that fail) then I would be willing to 
> look
> at them.

Excellent news. I guess that the problems we have are related to the 
fact that
we have old instances of users around in old wikis and this conflicts 
when we use the new
security model

> One thing we found annoying was that the default wiki with advanced 
> security
> gives no permissions at all to the anonymous user.  I think we changed
> initialization so that anonymous users can read and write pages and 
> create
> new pages.

Yes indeed this was strange.

> In general, all of the UIUC wiki will be open for reading and writing 
> by any
> user.  However, I have a class where I would like to provide private 
> folders
> for each student.  We made an action that will take a "students" 
> folder with
> a large number of subfolders and will automatically make users and 
> roles for
> each subfolder and set permisisons so that students can read and write 
> their
> own folders, but nobody else can read or write them.  In this class,
> students write short essays several times a week and take turns grading
> them.  I wanted to do this all on the wiki.  The grader must be able 
> to read
> the essays, but nobody else can read them until they are all turned 
> in.  I
> make a "VirtualFolder" structure that I can put in the folder of the 
> grader.
> If the student is supposed to grade essay 3, I will initialize the 
> virtual
> folder with the string "essay 3" and then the folder will act like it
> contains every page named "essay 3" in any of the student folders.  
> When the
> grader is finished grading the essays, he can make his virtual folder
> readable by the world, and then everybody can read the essays.  The 
> pages
> representing the essays will have two URLs, their original one and the 
> one
> through the virtual folder.  They will have different permssions 
> depending
> on which URL you use.
>
> We got all this to work and I was pleased.

This is nice. I would not have known how to make this works.
I think that SmallWiki will start to pay off as soon as you have non 
basic needs and in the
long run we are winning.

> The advanced security system is complex, and security depends on roles 
> being
> assigned correctly.  It would be useful to have some sort of an 
> analysis
> package that would make it easy to see who is allowed to do what to the
> various parts of the wiki.  For example, it could draw a diagram of 
> the wiki
> and color different parts with the roles that work on them.  Until 
> then, my
> solution will be to keep things very simple.  Except for this one 
> class,
> I'll just have the administrator and the anonymous role.

Yes I agree having a overall picture is currently missing. I think that 
with the new version
of SmallWiki building more advanced tools will be easier because writing
web widgets is not easy right now.