start | find | index | login or register | edit
Montag, 30. September 2002 link aYago

How To have a vanilla space that is open in principle but allows storage of kinda "confidential" information as well? - a gentle introduction to vanilla access control basics and ways to extend these mechanisms.

let's start with a quick overview of the vanilla access rights architecture. a reader in vanilla can be in one of 4 groups:
  • anonymous
  • registered user
  • associate
  • master
"higher level" groups inherit all rights of "lower level" groups. registration is open to anybody, to become an associate either the master or another associate has to promote the user.

besides du-jour, which has it's own rules (only registered users and higher can comment, nothing else matters) vanilla currently provides 4 security levels:
  • closed - read/write for assoc's only
  • read-only - read: everyone, write: assocs only
  • open - read: everyone, write: regged users only
  • totally open (the wiki mode :) - read/write for everyone
ok, now imagine the following situation: you want a vanilla space which is open for everyone to read, open for registered users to comment and which allows associates to write. - heh, "no problem", you'd say, "i'd use an read-only space for this", and hey, right you are! that's exactly what read-only spaces were intended to be :)

but let's add a small piece of complexity: certain pieces of information you want to store in the space, are confidential and only associates should be able to see these snips. here's how you'd accomplish that:
  • create a "confidential" dyna. this dyna checks that an user is logged in and that she is an associate. if these conditions are not met, it redirects to a "snip-confidential" snip, presenting the user with a nice error message :)

  • create this "snip-confidential" snip

  • add a call to the confidential dyna to every snip you want to be confidential

  • IMPORTANT: remove the display-raw selector from the valid-selectors list in vanilla.r - i'll explain why this is important a few paragraphs ahead :)
okay, sounds like a quite straightforward solution, doesn't it? let's examine possible "backdoors" - situations where the dyna is not executed but the snip content is shown.

non-assoc modifies to url-line to edit the snip: as only assocs are allowed to edit in read-only spaces, the user's request to edit will be declined.

transcluding the snip into another snip: no effect, as dyna execution will happen anyway.

so, now the smarter cases: vanilla has per default one selector, where dyna execution does not occur - the display-raw selector. this selector actually displays the snip's content as it is stored in vanilla's space-db. now if a real vanilla hacker would modify the url to request a display-raw on a snip with confidential information, vanilla would provide all the information wanted :)

and now you've another case why to never ever expose vanilla directories via http, so simply do not do it :) the only parts of vanilla which must reside in an http-accessible place are the CGI(-wrapper) and the according config.

so as you've seen, vanilla provides a quite simple basic set of access control which can easily enhanced by some small but useful bits. common usage scenarios can be achieved by critically assessing the options available. so before rolling your own mega ACL-based solution for vanilla (which would require in-depth knowledge of core vanilla mechanisms), have a deep look at what's already there :)

no comments

Please log in (you may want to register first) to post comments!

search

sep 30, in:

2010 / 2003 / 2002 / 2001

40 active users

backlinks (more)

none, yet

recent stores (more)

recent comments

powered by vanilla
echo earlZstrainYat|tr ZY @.
earl.strain.at • esa3 • online for 8662 days • c'est un vanilla site