Files @ abc1ada59076
Branch filter:

Location: kallithea/docs/usage/locking.rst

abc1ada59076 1.1 KiB text/prs.fallenstein.rst Show Annotation Show as Raw Download as Raw
Søren Løvborg
notifications: untangle notification access check

This removes a broken permission check when viewing notifications (the
HasRepoPermissionAny object was created, but never actually called with
a repo_name argument as required). It would be non-trivial to actually
implement the check, as notifications don't track their repository
relationship explicitly, and even then, it's unclear why it would
make sense to allow a repository admin to see notifications to
other users.

It was never a vulnerability, due to a subsequent (and much stricter)
ownership check, which remains but has been untangled for readability.
In short, this changeset is a pure refactoring, except that specifying
a non-existent notification ID will now produce error 404, not 403.
.. _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.