I dimly recall mention of being able to have both public and private webs on TWiki (say for customers and company internal) and i've looked through the documentation, but can't find anything on how to do this. Can someone either discuss how to do it or point me at the appropriate documentation?

I want to have a TWiki site where some webs are by password access only.

-- DavidLeBlanc - 15 Apr 2002

I guess you read TWikiAccessControl. I never tried for myself, but i heard DENYWEBVIEW and ALLOWWEBVIEW should handle it. What I am missing?

-- PeterMasiar - 15 Apr 2002

What you are missing is restricting access, not prohibiting it. DENYWEBVIEW prohibits, it does not restrict. I want to restrict access to selected users based on password, not just group or username. Thanks for the pointer though!

The information in TWikiAccessControl is interesting, but the first code snippet in the controlling access by web section is a bit scary - it isn't clear how it implements authentication and it uses hard coded information instead of TWiki preference variables. The second seems like too much of a hack and it doesn't say why it's less reliable.

-- DavidLeBlanc - 15 Apr 2002

There is ALLOWWEBVIEW as well as DENYWEBVIEW. TWikiAccessControl is correct in suggesting that access restrictions are limited in TWiki. They work as stated but TWiki and plugins have not been written to obey these restirctions everywhere. So they are fine for a fair level of protection, but they are limited. It would be more useful if you could say exactly what parts of TWikiAccessControl bother you - the current implementation is pretty easy to use and shares the same authenication mechanism as edit etc at present. My companies TWiki implementation uses these features, with uses being forced to authenicate for all scripts when viewing a Web with view restirctions.

-- JohnTalintyre - 16 Apr 2002

TWikiAccessControl descibes two options to restrict access to a web. The first option was added later and is a hack (it should be removed from the official doc and put somewehere like the TWikiAdminCookBook); the second option with viewauth is the original TWiki designed one and is not a hack (though some people label it that way). At work we use the second option successfully to restrict access to many engineering webs.

-- PeterThoeny - 17 Apr 2002

I assume in the case above you are referring to restrict access to particular webs in an otherwise unprotected wiki? That is, I assume you are referring to section "Restricting Web Access" in TWikiAccessControl, where the two options are

• Hidden Webs
• Authenticaticated Access By Web

I must admit, I have read this section several times and am still not clear on what precisely is meant. I had assumed that the first option, using ALLOWWEBVIEW and DENYWEBVIEW would be sufficient to allow or disallow viewing of a web by users that were already authenticated. Is this interpretation incorrect?

-- ThomasWeigert - 28 May 2002

I did some work on the TWikiAccessControl topic, "Restricting Web Access" is now "Restricting Read Access" and describes three different setups for restricting access to a web. Feedback and proof-reading is appreciated.

-- PeterThoeny - 29 May 2002

Thanks. This section is much clearer now. The only thing missing is a paragraph along the following lines:

" DENYWEBVIEW is evaluated before ALLOWWEBVIEW. Access is denied if the authenticated person is in the DENYWEBVIEW list, or not in the ALLOWWEBVIEW list. Access is granted in case DENYWEBVIEW and ALLOWWEBVIEW is not defined."

-- ThomasWeigert - 29 May 2002

Thanks for catching this. Is added.

-- PeterThoeny - 30 May 2002

I'd like to suggest adding to the TWikiAccessControl section dealing with read access an example of the .htaccess file with the viewauth section correctly added instead of view, as this is non-obvious (at least to myself).

-- RalphBroom - 05 Jun 2002

For the latest Alpha, the viewauth section is already in .htaccess by default.

-- PeterThoeny - 05 Jun 2002

In attempting to make a web, say Protectedweb, viewable only to a certain group, I am confident that I have followed the 5 step process in the subsection Authenticate and Restricting Selected Webs Only which ends with "When a user accesses a web where you enabled view restriction, TWiki will redirect from the view script to the viewauth script once (this happens only if the user has never edited a topic). Doing so will ask for authentication. The viewauth script shows the requested topic if the user could log on and if the user is authorized to see that web."

But in my case, when an unauthenticated user addresses /twiki/bin/view/Protectedweb/WebHome, rather than offering an authentication dialog, viewauth seems to provoke an http 403 "Forbidden" error for which my Apache 1.3.17 puts up a page with "You don't have permission to access /twiki/bin/viewauth/Protectedweb/WebHome on this server". Does this symptom show why my confidence is misplaced?

-- BobMorris - 29 Jun 2004

can you confirm that there really is a viewauth file in your cgi-bin dir, and that its permissions are the same as the other files? (on some of my systems I've had to create a copy of the view script as symbolic linking was disallowed)

-- SvenDowideit - 30 Jun 2004

Ah, you must be telepathic because just as you were writing this we realized symlinks disallowed would cause the symptom (Maybe here and elsehwere where a symlink is urged, it would be helpful to have a reminder that many installations have them severely restricted. There is a topic somewhere on Codev about this, but I couldn't find it.) From a sysadmin point of view what I really did wrong was that despite realizing I was seeing http errors, not TWiki errors, I never looked at the web server log, which of course is littered with "symlinks disallowed messages...."

-- BobMorris - 30 Jun 2004