kallithea Files · docs/usage/locking.rst

Files @ 9f976d75b04c

Branch filter:

Location: kallithea/docs/usage/locking.rst

9f976d75b04c 1.1 KiB text/prs.fallenstein.rst Show Annotation Show as Raw Download as Raw

Mads Kiilerich

auth: restore anonymous repository access

Dominik Ruf found that aa25ef34ebab introduced a regression in anonymous access
to repositories ... if that is enabled.

The refactoring was too strict when it missed that not all repo permission
checks require a logged in user. Read access can be granted to the default user
... but not write or admin.

Instead of the commands used in aa25ef34ebab, the following commands are used
to consistently also allow the default user in all decorators where we only need
repo read access:

# Introduce explicit allow_default_user=True - that was the default before aa25ef34ebab
sed -i 's/@LoginRequired()/@LoginRequired(allow_default_user=True)/g' `hg mani`
sed -i 's/@LoginRequired(\(..*\))/@LoginRequired(\1, allow_default_user=True)/g' `hg mani`
# The primary case: Replace @NotAnonymous with removal of allow_default_user=True
perl -0pi -e 's/\@LoginRequired\((?:(.*), )?allow_default_user=True\)\n\s*\@NotAnonymous\(\)/\@LoginRequired(\1)/g' `hg mani`
# If there is a global permission check, no anonymous is ever allowed
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)(\n\s*\@HasPermission)/\@LoginRequired()\1/g' `hg mani`
# Repo access for write or admin also assume no default user
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)(\n\s*\@HasRepoPermissionLevelDecorator\('"'(write|admin)'"'\))/\@LoginRequired()\1/g' `hg mani`

.. _locking:

==================
Repository locking
==================

Kallithea has a *repository locking* feature, disabled by default. When
enabled, every initial clone and every pull gives users (with write permission)
the exclusive right to do a push.

When repository locking is enabled, repositories get a ``locked`` flag.
The hg/git commands ``hg/git clone``, ``hg/git pull``,
and ``hg/git push`` influence this state:

- A ``clone`` or ``pull`` action locks the target repository
  if the user has write/admin permissions on this repository.

- Kallithea will remember the user who locked the repository so only this
  specific user can unlock the repo by performing a ``push``
  command.

- Every other command on a locked repository from this user and every command
  from any other user will result in an HTTP return code 423 (Locked).
  Additionally, the HTTP error will mention the user that locked the repository
  (e.g., “repository <repo> locked by user <user>”).

Each repository can be manually unlocked by an administrator from the
repository settings menu.