[pmwiki-users] Public/private wiki pages (was: PmWiki group)

[chr at home.se]

On Wed, 6 Apr 2005, Neil Herber wrote:

> At 2005-04-06  09:40 AM +0200, chr at home.se is rumored to have said:
> >Could this strategy help with keeping one part of the wiki "public" and
> >the rest "private"? This goes back to the desire of letting certain
> >customers and consultants access only certain pages.
> >
> >I've no experience with fields, but what if I created a "public" field and
> >then used the code above to let that field see "private" pages?

I should add that I also must have file attachments with similar access
control. Today I've simply created a separate "public" wiki with a 
separate uploads/, and access is controlled via .htaccess. Files that need 
to be shared are then simply soft links under uploads/.

> I think you can do most of what you want with groups and group-level read 
> passwords. I use a farm with fields to isolate completely different 
> clients. For example, FieldA for client A, FieldB for client B, and so on.

In our case we'll probably only want the client to access *some* of the 
pages that are related to him. That would mean using something like this:

	wiki/		- Private wiki, finds all pages
	  wiki.d/	- Private wiki pages
	  uploads/	- Contains all uploaded files 
	
	client-A/	- Public wiki for client A
	  wiki.d/	- Public wiki pages readable by client
	  uploads/	- Contains soft links to files in '../uploads/'

	client-B/	- Public wiki for client B
	  wiki.d/	- Public wiki pages readable by client
	  uploads/	- Contains soft links to files in '../uploads/'

where pages that should be at least readable by the client are stored in
	client-N/wiki.d/

and can be accessed through the private wiki because it appends the search
path with '../client-A/wiki.d' and '../client-B/wiki.d'.

Making a page "public" in this case simply means manually moving the file 
that stores the page from 'wiki/wiki.d/' to 'client-A/wiki.d'. That page 
will then show up as normal in both 'wiki/' and 'client-A'.
 
> Within a field, I use groups to isolate pages from client groups. For 
> example, FinanceGroup, AdminGroup, SalesGroup. I use read passwords to 
> control access to the groups (if needed).

Ok, so your suggestion could be interpreted as password protecting the 
groups within the field accordingly.

I'm a bit worried that the password mechanism in PmWiki isn't enough, or
that my users will accidentally put private information on a "public"  
page... (I'm using a big banner to indicate what's "public" right now, 
that helps a bit)).

> The only problem with this scheme is that out-of-the-box, PmWiki leaks 
> information about private groups via the search and pagelist directives. In 
> some cases this is not a problem.

It could definitely be problem in my case.

> Where you need complete privacy, you can easily add some lines to local
> config to protect the private groups. (I don't have those lines handy
> right now ... sorry!)

Thanks for your tips though, I'll have to check this out in more detail 
when I have some time.

regards
/Christian

-- 
Christian Ridderström, +46-8-768 39 44               http://www.md.kth.se/~chr