Access control by configuration keys
------------------------------------

While Gitano allows arbitrarily complex accss control via Lace, and supports
group and repository prefix matching to manage large projects, these approaches
are often overkill for installations with small numbers of repositories, users,
and permission grants.

Instead, the default ruleset for Gitano also supports adding users, by name, to the
config lists "project.readers" and "project.writers" allowing a much simpler
per-repository configuration approach.

Note:  This lookup is linear time, so it won't scale to a large number of users.
Also it doesn't automatically get updated if users are added/deleted/renamed.
If any of that concerns you, take the time to use a proper group and Lace approach.

    SCENARIO Access controlled by configuration keys

    GIVEN a standard instance
      AND testinstance using adminkey, adds a new user alice, with a key called main

By default users may not read repositories they are not owners to,
so cloning fails.

     WHEN testinstance adminkey runs create testrepo
      AND alice, using main, expecting failure, clones testrepo as testrepo
     THEN stderr contains \(FATAL: Not authorised\|The requested URL returned error: 403\)

When the user is added to the project.reader config then cloning works.

     WHEN testinstance adminkey runs config testrepo set project.readers.* alice
      AND alice, using main, clones testrepo as testrepo
     THEN alice has a clone of testrepo

Pushing any content fails however.

     WHEN alice using main pushes an empty commit in testrepo
     THEN stderr contains \(FATAL: Not authorised\|The requested URL returned error: 403\)

Pushing works once the user is added to project.writers.

     WHEN testinstance adminkey runs config testrepo set project.writers.* alice
      AND alice applies add-a-FOO.patch in testrepo
      AND alice, using main, pushes testrepo to testrepo.git
      AND server-side testrepo reads git object HEAD
     THEN stdout contains Apply add-a-FOO.patch content change

Being a project writer implies also being a project reader.

     WHEN testinstance adminkey runs config testrepo del project.readers.i_1
      AND alice, using main, clones testrepo as testrepo2
     THEN alice has a clone of testrepo2

    FINALLY the instance is torn down