Re: [emacs-wiki-discuss] Re: Access control for published pages

[jorge]

address@hidden (Andrew J. Korty) writes:

> Gerd Flaig <address@hidden> writes:
>
>>     1. Change emacs-wiki so it can publish to a list of publishing
>>        locations
>>
>>     2. Add another tag (<private> maybe?) to publishing-markup that
>>        omits its content when publishing to a location not marked
>>        private
>
> That might work for some.  I want my boss to be able to read certain
> entries that other people can't.  But I want him to be able to read
> the public pages, too, and I'd prefer not to make him visit more than
> one site to do so.

...
> Someone mentioned that Mason is overkill, and I tend to agree.  We
> only need the logic portion (not the caching, test environment, etc.),
> so server-side includes or the Template Toolkit might work instead.
> I'd like to make it work without anything external, but I haven't
> figured out how to do so while fulfilling all my requirements.
...

The natural entity of a Wiki is one directory with a bunch of pages, the
natural boundary for access control in a Webserver is a directory[1].

What we are dealing with, when working with access control can be seen
as either various diferent "views" of an entity, or several
linked-together entities with different access rights.

The "Owner" of the information wants to see/edit the whole
information and be able to share different selected views with
determinated groups of people.

Emacs-Wiki allows to set emacs-wiki-directories to a list of directories
rather than to only one directory, so it widens the concept of the
entities.  However my actual (in)experience shows, that useing several
directories to spread the Wiki pages instead of only one does not really
work[2][3].  If it *would* work, each directory (or a group of them)
could be asociated with a *View*, and published independently to
different directories of the Webserver, hence shielded easily from
access by unauthorized visitors.

My proposal (after fixing multiple directories): a variable or function:

  emacs-wiki-published-directories

Which evaluates to the list of directories to which publishing is
restricted.  The default-value would be emacs-wiki-directories.

To create differentiated views of the project, a set of the variables:
emacs-wiki-published-directories, emacs-wiki-publishing-directory,
emacs-wiki-project-server-prefix, et al would be switched on demand.

A second proposal is the introduction of emacs-wiki-current-directory,
which would be the directory in which all new pages will be created,
i.e. if an unknown WikiLink is followed, the new page is created in the
directory indicated by this variable.  So one can select consciously in
which "View" a certain contents is created.

These proposals are just a remake of a similar one, which uses a
diferent interpretation of emacs-wiki-directories[4].  All of them are
really just vaporware, because I have still not managed to dig Elisp and
Emacs-Wiki sufficiently to be able to make them by myself.

Regards,

        Jorge-León


[1] Apache can control access to individual files, it's a lot of
configuration work, however.  Other Webservers, for example WN, only
support access control for whole directory trees.

Deficiencies of emacs-wiki-directories handling:

[2] Namespace ambiguity: If e.-w.-directories is ("~/A" "~/B") and in
    both directories exists a file named "SameFile" then the Wiki Link
    SameFile *always* returns the first of them, in this case
    "~A/SameFile".  I can think of a way to disambiguate dinamically
    duplicate wiki names *and* this would also include dealing with
    linking correctly but it would be somewhat elaborate and intrusive
    to the actual emacs-wiki (at least this is what I think).

[3] If severaly directories are put into e.-w.-directories, (unambiguos)
    links are followed correctly, and new pages are created inside the
    directory where the page resides in which the link is first created.
    This is not wrong, but can be not what is wanted.

Older proposal:

[4] emacs-wiki-directories is constructed the following way:

   (current-directory pub1 pub2 pub3 ... (priv1 priv2 priv3))

   - the first entry in the list is, where new pages go to.
   - all members of the list which are not a list by itself are
   - directories to be published.

   This notation would suffice to go without aditional variables, or can
   be constructed from the above proposed variables:

   - if only exists one directory the list of private is () - end of the
     list = backwards compatible.
   - to change the view of the project, the list just has to be shuffled
     so that the now "invisible" directories go into the list at the end
     of the list.
   - to change the current directory the list just has to be shuffled
     so the new current directory gets to the front of the list.