[pmwiki-users] Restricting information (Was: General Farming Questions)

chr at home.se chr at home.se
Thu Sep 29 02:15:23 CDT 2005


I have a slightly different situation which I thought I should bring up, 
maybe others are in the same situation.

My company uses pmwiki for collaboration on the intranet. This is a
restricted network only for employees. Now, sometimes we might want to
share information with a customer or a consultant, i.e. allow then access
to certain pages/groups. It can be *important* to not let customers see
the wrong pages, or even know that they *exist*. (Let's say a customer
requires us to keep his identity secret from his competitors, i.e.  
customer A may not know that we also sell to customer B).

We haven't implemented anything like this yet, but so far I had thought
that it'd have to be implemented using wiki fields:

* A "root" wiki field, strictly internal, with e.g. these pages
* A separate wiki field for information that customer A may see

* Another separate wiki field that customer B may see

I'm assuming I'd use .htaccess to protect the wiki fields, here's
.htaccess that'd protect the "root" field available to employees would
look like this:

	AuthUserFile /srv/www/htdocs/.htpasswd
	AuthGroupFile /srv/www/htdocs/.htgroup
	Require group Employees

where the file .htgroup lists usernames in the group Employes. Similarly, 
for the field CustomerA, we'd have this .htaccess:

	AuthUserFile /srv/www/htdocs/.htpasswd
	AuthGroupFile /srv/www/htdocs/.htgroup
	Require group Employees CustomerA

Customers might need to download files, which would be handled using a 
separate upload/ directory for each field.

The solution above does satisfy the secrecy requirements, but it's more 
difficult for us to work with. I need to create a separate field for each 
customer for one... and we might end up with almost the same page in two 
different fields.

I should also say that I don't really expect a need for customers to be
able to edit pages. Nor do I expect that there will be that many pages in
the customer fields. The pages would contain some documentation about the
product that the customer uses, but primarily links to other documents.

Anyway, now over to something Patrick wrote, which I hope might be useful
in this context:

On Wed, 28 Sep 2005, Patrick R. Michaud wrote:

> In the local/config.php, add the line:
>     if (@$_SERVER['REMOTE_USER']) $AuthId = $_SERVER['REMOTE_USER'];
> This tells PmWiki to honor any authentication performed by the 
> webserver, and we continue to allow Apache to perform the authentication
> (and you continue to use your web admin GUI and maintain passwords
> there).
> Then, to limit access to a group XYZ to users alice, bob, and carol,
> simply set the read password of XYZ.GroupAttributes to
>     id:alice,bob,carol
> Anyone who isn't logged in as alice, bob, or carol won't be able
> to read the pages in that group.  
> Further, if you set $EnablePageListProtect=1, then even searches
> and pagelists will only show those pages for which the currently
> logged in user has read access.

What I wonder is of course if the above would allow me to re-structure my 
solution without using separate wiki fields for each customer. Basically, 
I wonder if I could use a structure like this instead:

	CustomerA.CustomerA	- not accessable by customer
	A.A			- accessable by customer

where customer A is *only* allowed to access the group 'A'.

Assuming this is the case, is there an easy way to retrieve the name of 
the group(s) that the user belongs to?  (I'd like to keep controlling 
group membership in the file .htgroups). Parsing .htgroups myself is of 
course an option.

phew... sorry about the long post.


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

More information about the pmwiki-users mailing list