30 lines
1.2 KiB
Plaintext
30 lines
1.2 KiB
Plaintext
|
[[!comment format=mdwn
|
||
|
username="http://smcv.pseudorandom.co.uk/"
|
||
|
nickname="smcv"
|
||
|
subject="comment 1"
|
||
|
date="2012-04-15T20:53:44Z"
|
||
|
content="""
|
||
|
Read/view access and write/edit access are rather different.
|
||
|
You can limit write access via wiki configuration, and even
|
||
|
configure it over the web with [[plugins/websetup]].
|
||
|
|
||
|
The only way to limit read access is to restrict access to the
|
||
|
entire wiki via `.htaccess` or other web server configuration,
|
||
|
preferably combined with use of `https`.
|
||
|
IkiWiki can't limit read access to pages on its own[*],
|
||
|
because it's a wiki compiler: when a page is viewed, the web
|
||
|
server serves the compiled HTML without IkiWiki being involved.
|
||
|
|
||
|
The best way to integrate access control into IkiWiki would
|
||
|
probably be to have a CGI user interface for `.htaccess` or
|
||
|
equivalent - but you'd still have to be careful, because,
|
||
|
for instance, if a user can edit public pages, then they
|
||
|
can insert a `\[[!include]]` directive to make the content
|
||
|
of a private page public. As a result, the safest way to
|
||
|
use it is to keep public and private information in
|
||
|
separate wikis.
|
||
|
|
||
|
[\*] strictly speaking, it *could* via a new plugin, but
|
||
|
that would defeat many of its advantages
|
||
|
"""]]
|