Question

Apologies if folk feel this is FAQ but I've gone through the docs every which way and it makes my head spin. Possobly coz the docs are trying to cover several different methods interleaved.

I'm looking for specific setup for a Web where some pages can be "Public", some can be "public view, auth to edit" and some MUST be "auth to view".

More Details

I have Twiki up and running just fine on a shiney new Debian box.

However, much as we appreciate the "open" ethos of Wiki as a whole, and, indeed, plan to use it extensively, we have a particular requirement which is not best suited to allowing anyone in.

We want to be able to log support information about client systems on Wiki pages so that our field engineers can access, and ammend it, from anywhere. Especially from client sites. But we clearly don't want anyone on the planet accessing info about our client's systems. So we need to create a Web with three classes of page

1. Main pages, can be open to anyone as usual. We'll include a welcome page telling Joe Anyone he's probably found the wrong place and giving him places to go.
2. General support pages, which we can make visible to anyone, but not allow editing.
3. Most importantly, private pages which users can't even access without logging in and that login ID being on the list for the page in question, or for a "subset" of pages or even, if it would be easier, an entire separate "web". ( Merely hiding the URL is not sufficient, it MUST reject un-known users from accessing the pages even if they know the URL. )

I've managed to set up a Login Required To Edit with .htpasswd in .../twiki/data, but trying to extend the scope of this to achieve the above results makes my head spin. The documents are extensive - but on the subect of Authentication, there are several "interleaved" methods and I can't unravel the bits I need from the rest.

Suggestions welcome.

Environment

-- ChrisComley - 27 Jul 2005

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

There is a corollary to this:

• Define a web with a default of auth to view, auth to edit
• Have specific pages, such as WebHome. which tells users to register, that are explicitly anyone can view

I would think that this would be a common enough setup that it wold be explicitly documented. After all, TWiki positions itself as a Wiki for corporate settings and in a corporate setting a restricted web is likely to be copmmon - viz marketing, finance, or 'new product development'.

-- AntonAylward - 27 Jul 2005

It sounds like you've got a public twiki with a type of "members only" need for viewing and/or editing. I've got a couple of TWikis just like this. So just supporting and filling out what Anton says this is how I handle the situation you've got.

The authentication setup is integral with your information architecture decisions on what webs will do what and also with your construction of user groups for your site.

As you have found it is a multi-layered thing, but quite logical (bearing in mind that logic is in the eye of the beholder and there seem to be a lot of different opinions about webs in the codev group) once it clicks into place, I work this way with it all :

1. decide on how the access needs map out as a web entity/identity and structure/create webs accordingly. This feeds off the user needs analysis process.
2. set up TWikiGroups that map against those identities/webs if there is a need to restrict edit or view beyond the normal TWikiAdminGroup.
3. place allowtopic view access control settings on the WebPreferences page of fully private webs.
4. place allowtopicview and/or allowtopicchange settings on relevant pages on the public or semi public pages.
5. for fully private webs change the settings in their WebPreferences topic(s) to stop the web(s) being shown in the site map (if you want that to happen) and to stop the web(s) from being included in a Search all webs search. (PS - this latter setting can be a pain if you want to move topics around because it also has the effect of the web not being listed in the drop down list box when you are using the move function from More Topic Actions).
6. place a note on the registration page for new users saying that membership of some (or all webs) is moderated and there might be a short delay while membership privileges are assigned.

It means a bit of ongoing work in that the TWikiAdminGroup needs to keep the access control groups up to date as people come and go. I don't know of a way to simplify this. I can imagine it would be a pain in a very large organisation (although perhaps the problem may be somewhat simplified if you are running the TWiki as an Intranet).

I'd love to be able to streamline the membership moderation bit of this - I vaguely think there might be something in Dakar along these lines. Anyone?

I got really confused with all this at the start. My breakthrough thinking was when I realised that the access controls were set using the browser interface to access the WebPreferences and TWikiPreferences topics, and group creation tool. From the web background I came from where access control was set at the server level this was quite a discovery That feature makes it a bit surprising though that when I delete a user I've still got to go into the .htpasswd file to remove their login. But its all a work-in-progress and hopefully this kind of inconsistency will get fixed up over time as people bring forward ideas and suggestions.

Here's a For Example Structural Overview.

-- SueLocke - 28 Jul 2005

Thanks for the input, Sue.

It sounds like I'm better off setting up an entire secure "web" for the stuff that needs to be private, and sticking with the public web but with "auth for edit" (which we already have sussed) for the public-visible stuff.

Now I wonder if there's a quick and easy way of slurping a whole raft of pages from one Web into another or is it good news that there are only a few pages to cut and paste?

-- ChrisComley - 29 Jul 2005

You can always move things around at the server level as long as you haven't got internal links in TWiki ML. If you have you'll need to go back in to the pages and update the web references and possibly the parent topic linkage. Probably good news that you've got only got a few pages before you struck the authentication issue big time.

-- SueLocke - 29 Jul 2005