- Before that change on each requests 4x we loaded plugins for authentication, this hit
many caches, db invalidation context and loaded the plugins logic each time. This was a heavy performance hit
for SVN and other backends as they needed to load that plugins many many times
- Since Authentication plugins almost never change, we'll not store the plugins listed for authentication into
the authnregistry for each process
- For AuthPlugins settings we now also flush plugins settings, and authnregistry cached plugins
- use new exceptions for branch permissions
- detect if we need to check permissions
- calculate super-admin the same way as regular users for override capabilities
- added new tests for branch permissions
- This change will allow SVN to execute rhodecode integration framework
via executing the builting hooks.
- uses txn_id for svn to provide metadata required via Apache
- Interception of SVN transaction is required to use temporary stores for metadata
- hooks are now part of vcsserver where the install/control logic is stored
- especially for mysql in case large number of data in caches there could be critical errors storing cache, and thus preventing
users from authentication. This is caused by the fact that we used single namespace for ALL users. It means it grew as number of users grew
reaching mysql single column limit.
This changes the behaviour and now we use namespace per-user it means that each user-id will have it's own cache namespace fragmenting maximum column data to
a single user cache. Which we should never reach.
- this solves a case when SVN repository needs to find out a repo without
per-repo settings available
- we need to get the global config first to be able to extract repo name
- dependencies: bumped:
-setuptools-scm==1.15.6
-celery==4.1.0
-kombu==4.1.0
-pytz==2017.3
-Routes==2.4.1
Removed all pylons components. Refactored the code to use only pyramid
parts
- this gives a 30% speed increase in operations like svn commit
- generally uses the same mechanismy like auth cache to cache permissions for faster
access to vcs commands
We we to know to detect vcs type request as early as possible. IF we know
we're handling an VCS request, we can skip some of the pylons stack initialization.
- This fixes issues with leaking sessions and other object from pylons into
a purely VCS type request.
