Tags:
create new tag
, view all tags
With the 01 Dec 2000 release it is possible to write protect topics and webs as described in AuthenticationBasedOnGroups and TWikiAccessControl.

The next step is to control read access of topics and webs. The code is mostly there, i.e. use ALLOWTOPICREAD instead of ALLOWTOPICCHANGE.

To do:

  • Protect topic view
  • Protect search (performance issues)
  • Protect server side %INCLUDE% of topics (performance issues)
  • Figure out how to know who is looking at a topic without basic authentication for the view script. This has been partially solved by remembering the IP address / username pair whenever an authentication happens (edit topic, attach file), as described in WhoIsTheRemoteUserInView.

-- PeterThoeny - 26 Nov 2000

If I'm not mistaking, most of this work is done:

  1. Protect topic view - done in bin/.htaccess with <Files view>
  2. Protect search - I'm still thinking about this one. The performance issues come into consideration when one discovers that each page has to be searched for access permissions. (But they also have to be searched for the string anyway).
  3. Protect server side %INCLUDE% of topics - I think this is a non-issue - if the included file has access control in it, then it would be acted on, given the way checkAccessPermission works.
  4. Figure out who is viewing a topic without authentication - if one doesn't have authentication, then its effectively a public page (i.e. TWikiGuest is always seeing it). So I believe this is a non-issue (I'm prepared to be convinced otherwise).

-- BruceDawson - 18 Feb 2001

> Protect topic view - done in bin/.htaccess with <Files view>

Can be done. Has the implication that viewing general webs like TWiki.Main also ask for authentication,which might turn away contributors.

> Protect server side %INCLUDE% of topics - I think this is a
> non-issue - if the included file has access control in it, then it
> would be acted on, given the way checkAccessPermission works.

Correct. Not done yet.

> Figure out who is viewing a topic without authentication - if one
> doesn't have authentication, then its effectively a public page
> (i.e. TWikiGuest is always seeing it). So I believe this is
> a non-issue (I'm prepared to be convinced otherwise).

This can be done on an Intranet where the IP addresses don't change so frequently by enabling the $doRememberRemoteUser flag. At work I made a hack where the non authenticated view script checks if the page needs authorization. If yes and if the user is not remembered it redirects to the viewauth script, which is under authentication and which is a hard link to the view script.

-- PeterThoeny - 24 Feb 2001

What about setting these page permissions on the page, so that a user / process can set that a page is private to selected people, and similarly, I was thinking at one stage that it might be interesting to be able to encrypt the contents of a topic smile and that the decryption takes place using some javascript on the local users browser (with a dialog for the key..)

-- SvenDowideit - 25 Feb 2001

Read access can be restricted also on the topics level, basically it works the same way like the change restriction. It is not documented because the current implementation has above mentioned flaws of being able to cicumvent the restriction.

Decrypting data on the user's browser is an interesting idea. It would raise the RequiredEnvironmentForTWiki. How about encryption, does that happen on the server side when saving a topic?

-- PeterThoeny - 26 Feb 2001

i hadn't thought about implementation.. but as far as the idea goes, the unencrylted version should only be on the client.. so the edit component would need to have soem javascript too.. -- SvenDowideit - 27 Feb 2001

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2004-01-01 - SvenDowideit
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.