{"id":13468786,"url":"https://github.com/raphaelm/django-scopes","last_synced_at":"2025-04-04T20:12:30.238Z","repository":{"id":34876395,"uuid":"185976576","full_name":"raphaelm/django-scopes","owner":"raphaelm","description":"Safely separate multiple tenants in a Django database","archived":false,"fork":false,"pushed_at":"2023-07-17T06:51:20.000Z","size":60,"stargazers_count":229,"open_issues_count":13,"forks_count":15,"subscribers_count":13,"default_branch":"master","last_synced_at":"2024-10-17T10:13:18.863Z","etag":null,"topics":["django"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/raphaelm.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":"AUTHORS"}},"created_at":"2019-05-10T11:27:07.000Z","updated_at":"2024-10-15T08:02:58.000Z","dependencies_parsed_at":"2024-01-18T20:05:26.292Z","dependency_job_id":null,"html_url":"https://github.com/raphaelm/django-scopes","commit_stats":{"total_commits":37,"total_committers":6,"mean_commits":6.166666666666667,"dds":0.5405405405405406,"last_synced_commit":"e3d736b4b7d86101e052d6daead6da961ede4326"},"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raphaelm%2Fdjango-scopes","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raphaelm%2Fdjango-scopes/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raphaelm%2Fdjango-scopes/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raphaelm%2Fdjango-scopes/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/raphaelm","download_url":"https://codeload.github.com/raphaelm/django-scopes/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247242680,"owners_count":20907134,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["django"],"created_at":"2024-07-31T15:01:19.079Z","updated_at":"2025-04-04T20:12:30.215Z","avatar_url":"https://github.com/raphaelm.png","language":"Python","funding_links":[],"categories":["Python"],"sub_categories":[],"readme":"django-scopes\n=============\n\n![Build status](https://github.com/raphaelm/django-scopes/actions/workflows/tests.yml/badge.svg)\n![PyPI](https://img.shields.io/pypi/v/django-scopes.svg)\n[![Python versions](https://img.shields.io/pypi/pyversions/django-scopes.svg)](https://pypi.org/project/django-scopes/)\n![PyPI - Django Version](https://img.shields.io/pypi/djversions/django-scopes)\n\nMotivation\n----------\n\nMany of us use Django to build multi-tenant applications where every user only ever\ngets access to a small, separated fraction of the data in our application, while\nat the same time having *some* global functionality that makes separate databases per\nclient infeasible. While Django does a great job protecting us from building SQL\ninjection vulnerabilities and similar errors, Django can't protect us from logic\nerrors and one of the most dangerous types of security issues for multi-tenant\napplications is that we leak data across tenants.\n\nIt's so easy to forget that one ``.filter`` call and it's hard to catch these errors\nin both manual and automated testing, since you usually do not have a lot of clients\nin your development setup. Leaving [radical, database-dependent ideas](https://github.com/bernardopires/django-tenant-schemas)\naside, there aren't many approaches available in the ecosystem to prevent these mistakes\nfrom happening aside from rigorous code review.\n\nWe'd like to propose this module as a flexible line of defense. It is meant to have\nlittle impact on your day-to-day work, but act as a safeguard in case you build a\nfaulty query.\n\nInstallation\n------------\n\nThere's nothing required apart from a simple\n\n\tpip install django-scopes\n\nCompatibility\n-------------\n\nThis library is tested against **Python 3.8-3.11** and **Django 3.2-4.2**.\n\nUsage\n-----\n\nLet's assume we have a multi-tenant blog application consisting of the three models ``Site``,\n``Post``, and ``Comment``:\n\n```python\nfrom django.db import models\n\nclass Site(models.Model):\n\tname = models.CharField(…)\n\nclass Post(models.Model):\n\tsite = models.ForeignKey(Site, …)\n\ttitle = models.CharField(…)\n\nclass Comment(models.Model):\n\tpost = models.ForeignKey(Post, …)\n\ttext = models.CharField(…)\n```\n\nIn this case, our model `Site` acts as the tenant for the blog posts and their comments, hence\nour application will probably be full of statements like\n``Post.objects.filter(site=current_site)``, ``Comment.objects.filter(post__site=current_site)``,\nor more complex when more flexible permission handling is involved. With **django-scopes**, we\nencourage you to still write these queries with your custom permission-based filters, but\nwe add a custom model manager that has knowledge about posts and comments being part of a\ntenant scope:\n\n```python\nfrom django_scopes import ScopedManager\n\nclass Post(models.Model):\n\tsite = models.ForeignKey(Site, …)\n\ttitle = models.CharField(…)\n\n\tobjects = ScopedManager(site='site')\n\nclass Comment(models.Model):\n\tpost = models.ForeignKey(Post, …)\n\ttext = models.CharField(…)\n\n\tobjects = ScopedManager(site='post__site')\n```\n\nThe keyword argument ``site`` defines the name of our **scope dimension**, while the string\n``'site'`` or ``'post__site'`` tells us how we can look up the value for this scope dimension\nin ORM queries.\n\nYou could have multi-dimensional scopes by passing multiple keyword arguments to\n``ScopedManager``, e.g. ``ScopedManager(site='post__site', user='author')`` if that is\nrelevant to your usecase.\n\nNow, with this custom manager, all queries are banned at first:\n\n\t\u003e\u003e\u003e Comment.objects.all()\n\tScopeError: A scope on dimension \"site\" needs to be active for this query.\n\nThe only thing that will work is ``Comment.objects.none()``, which is useful e.g. for Django\ngeneric view definitions.\n\n### Activate scopes in contexts\n\nYou can now use our context manager to specifically allow queries to a specific blogging site,\ne.g.:\n\n```python\nfrom django_scopes import scope\n\nwith scope(site=current_site):\n\tComment.objects.all()\n```\n\nThis will *automatically* add a ``.filter(post__site=current_site)`` to all of your queries.\nAgain, we recommend that you *still* write them explicitly, but it is nice to know to have a\nsafeguard.\n\nOf course, you can still explicitly enter a non-scoped context to access all the objects in your\nsystem:\n\n```python\nwith scope(site=None):\n\tComment.objects.all()\n```\n\nThis also works correctly nested within a previously defined scope. You can also activate multiple\nvalues at once:\n\n```python\nwith scope(site=[site1, site2]):\n\tComment.objects.all()\n```\n\nSounds cumbersome to put those ``with`` statements everywhere? Maybe not at all: You probably\nalready have a middleware that determines the site (or tenant, in general) for every request\nbased on URL or logged in user, and you can easily use it there to just automatically wrap\nit around all your tenant-specific views.\n\nFunctions can opt out of this behavior by using\n\n```python\nfrom django_scopes import scopes_disabled\n\n\nwith scopes_disabled():\n    …\n\n# OR\n\n@scopes_disabled()\ndef fun(…):\n    …\n```\n\nPlease note that **django-scopes** is also active during migrations, so if you are writing a\ndata migration – or have written one in the past! – you'll have to add appropriate scoping\nor use the ``scopes_disabled`` context.\n\n### Custom manager classes\n\nIf you were already using a custom manager class, you can pass it to a `ScopedManager` with the `_manager_class`\nkeyword like this:\nfrom django.db import models\n\n```python\nfrom django.db import models\n\nclass SiteManager(models.Manager):\n\n\tdef get_queryset(self):\n\t\treturn super().get_queryset().exclude(name__startswith='test')\n\nclass Site(models.Model):\n\tname = models.CharField(…)\n\n\tobjects = ScopedManager(site='site', _manager_class=SiteManager)\n```\n\n\n### Scoping the User model\n\nAssume you've got two models `User` and `Post`. Using the examples above, you can ensure that users only ever see their own diary posts. But how about leaking other users to the currently logged in user? If you application doesn't have much (or any) interaction between users, you can scope the user model. Please note that you'll need a [custom user model](https://docs.djangoproject.com/en/dev/topics/auth/customizing/#specifying-a-custom-user-model). Which base classes your user and manager work off will very between projects.\n\n```python\nclass User(AbstractUser):\n\tobjects = ScopedManager(user='pk', _manager_class=UserManager)\n\n\t# (...)\n```\n\nActivating the scope comes with a little caveat - you need to use the users primary key, not the whole object:\n\n```python\nwith scope(user=request.user.pk):\n\t# do something :)\n```\n\nCaveats\n-------\n\n### Locking\n\nWith django-scopes, a seemingly innocent query like\n\n```python\nComment.objects.select_for_update().get(pk=3)\n```\n\ncould cause unexpected locking across your database, since django-scopes will auto-add one or more ``JOIN`` statements to the query, and joined tables will **also be locked**.\nOne possible fix is of course using ``scopes_disabled()``, around this query.\nOn most modern databases, there's also a way to specify explicitly which tables you want locked:\n\n```python\nComment.objects.select_for_update(of=(\"self\",)).get(pk=3)\n```\n\nYou can check if your database supports this feature at runtime using ``connection.features.has_select_for_update_of``.\n\n### Admin\n\n**django-scopes** is not compatible with the django admin out of the box, integration requires a\ncustom middleware. (If you write one, please open a PR to include it in this package!)\n\n### Testing\n\nWe want to enforce scoping by default to stay safe, which unfortunately\nbreaks the Django test runner as well as pytest-django. For now, we haven't found\na better solution than to monkeypatch it:\n\n```python\nfrom django.test import utils\nfrom django_scopes import scopes_disabled\n\nutils.setup_databases = scopes_disabled()(utils.setup_databases)\n```\n\nYou can wrap many of your test and fixtures inside ``scopes_disabled()`` as well, but we wouldn't advise to do it with all of them: Especially when writing higher-level functional tests, such as tests using Django's test client or tests testing celery tasks, you should make sure that your application code runs as it does in production. Therefore, writing tests for a project using django-scopes often looks like this:\n\n```python\n@pytest.mark.django_db\ndef test_a_view(client):\n    with scopes_disabled():\n        u = User.objects.create(...)\n    client.post('/user/{}/delete'.format(u.pk))\n    with scopes_disabled():\n    \tassert not User.objects.filter(pk=u.pk).exists()\n```\n\nIf you want to disable scoping or activate a certain scope whenever a specific fixture is used, you can do so in py.test like this:\n\n```python\n@pytest.fixture\ndef site():\n    s = Site.objects.create(...)\n    with scope(site=s):\n        yield s\n```\n\nWhen trying to port a project with *lots* of fixtures, it can be helpful to roll a small py.test plugin in your ``conftest.py`` to just globally disable scoping for all fixtures which are not yielding fixtures (like the one above):\n\n```python\n@pytest.hookimpl(hookwrapper=True)\ndef pytest_fixture_setup(fixturedef, request):\n    if inspect.isgeneratorfunction(fixturedef.func):\n        yield\n    else:\n        with scopes_disabled():\n            yield\n```\n\n### ModelForms\n\nWhen using model forms, Django will automatically generate choice fields on foreign\nkeys and many-to-many fields. This won't work here, so we supply helper field\nclasses ``SafeModelChoiceField`` and ``SafeModelMultipleChoiceField`` that use an\nempty queryset instead:\n\n```python\nfrom django.forms import ModelForm\nfrom django_scopes.forms import SafeModelChoiceField\n\nclass PostMethodForm(ModelForm):\n    class Meta:\n        model = Comment\n        field_classes = {\n            'post': SafeModelChoiceField,\n        }\n```\n\n### django-filter\n\nWe noticed that ``django-filter`` also runs some queries when generating filtersets.\nCurrently, our best workaround is this:\n\n```python\nfrom django_scopes import scopes_disabled\n\nwith scopes_disabled():\n    class CommentFilter(FilterSet):\n        …\n```\n\n### Uniqueness\n\nOne subtle class of bug that can be introduced by adding django-scopes to your project is if you try to generate unique identifiers in your database with a pattern like this:\n\n```python\n\ndef generate_unique_value():\n    while True:\n        key = _generate_random_key()\n        if not Model.objects.filter(key=key).exists():\n            return key\n```\n\nIf you want keys to be unique across tenants, make sure to wrap such functions with ``scopes_disabled()``!\n\nWhen using a [ModelForm](https://docs.djangoproject.com/en/dev/topics/forms/modelforms/) (or [class based view](https://docs.djangoproject.com/en/dev/topics/class-based-views/)) to create or update a model, unexpected IntegrityErrors may occur. ModelForms perform a uniqueness check before actually saving the model. If that check runs in a scoped context, it cannot find conflicting instances, leading to an IntegrityErrors once the actual `.save()` happens. To combat this, wrap the call in ``scopes_disabled()``.\n\n```python\nclass Site(models.Model):\n    name = models.CharField(unique=True, …)\n\n    # (...)\n\n    def validate_unique(self, *args, **kwargs):\n        with scopes_disabled():\n            super().validate_unique(*args, **kwargs)\n```\n\n## Further reading\n\nIf you'd like to read more about the practical use of django-scopes, there is a [blog\npost](https://behind.pretix.eu/2019/06/17/scopes/) about its introduction in the [pretix](https://pretix.eu) project.\n\n[Here](https://rixx.de/blog/using-the-django-shell-with-django-scopes/) is a guide on how to write a ``shell_scoped``\ndjango-admin command to provide a scoped Django shell.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraphaelm%2Fdjango-scopes","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fraphaelm%2Fdjango-scopes","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraphaelm%2Fdjango-scopes/lists"}