Added a comment
parent
c25d6863ed
commit
34e21ee99f
|
@ -0,0 +1,29 @@
|
|||
[[!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
|
||||
"""]]
|
Loading…
Reference in New Issue