All Projects → raratiru → django-letsagree

raratiru / django-letsagree

Licence: BSD-3-Clause license
A Django application that associates Groups with Terms requiring consent from logged in members.

Programming Languages

python
139335 projects - #7 most used programming language
HTML
75241 projects
CSS
56736 projects

Projects that are alternatives of or similar to django-letsagree

gothic
🦇 Gothic is a user registration and authentication SWT/JWT microservice. It supports REST, gRPC, and gRPC Web API, reCAPTCHA & a variety of DBs with Gorm.
Stars: ✭ 65 (+441.67%)
Mutual labels:  authorization
MovieGo
A Website implemented using MERN (MongoDB, ExpressJS, ReactJS and NodeJS) stack, which allows users to sign-in/register and book movie tickets online.
Stars: ✭ 26 (+116.67%)
Mutual labels:  authorization
active admin role
Role based authorization with CanCanCan for Active Admin
Stars: ✭ 53 (+341.67%)
Mutual labels:  authorization
gotrue
A JWT based API for managing users and issuing JWT tokens
Stars: ✭ 325 (+2608.33%)
Mutual labels:  authorization
authorize-me
Authorization with social networks
Stars: ✭ 44 (+266.67%)
Mutual labels:  authorization
opa-docker-authz
A policy-enabled authorization plugin for Docker.
Stars: ✭ 67 (+458.33%)
Mutual labels:  authorization
react-redux-jwt-auth
React Redux: Token Authentication example with JWT, React Router, Axios, Thunk Middleware
Stars: ✭ 86 (+616.67%)
Mutual labels:  authorization
Django-CRM-Project
Django CRM Project - Youtube Tutorial
Stars: ✭ 108 (+800%)
Mutual labels:  django-application
soak-your-brain-elearning-app
An e-learning platform built in python (django)
Stars: ✭ 18 (+50%)
Mutual labels:  django-application
django-cancan
🔓Authorization library for Django
Stars: ✭ 36 (+200%)
Mutual labels:  authorization
dart-casbin
An authorization library that supports access control models like ACL, RBAC, ABAC in Dart/Flutter
Stars: ✭ 30 (+150%)
Mutual labels:  authorization
beyondauth
a traefik / nginx companion to create an identity aware proxy like beyondcorp
Stars: ✭ 26 (+116.67%)
Mutual labels:  authorization
xlsx over web
Django开发的excel表格展示系统,将本地xlsx文件导入到数据库,显示到JS页面 online excel manage with django
Stars: ✭ 27 (+125%)
Mutual labels:  django-application
lua-casbin
An authorization library that supports access control models like ACL, RBAC, ABAC in Lua (OpenResty)
Stars: ✭ 43 (+258.33%)
Mutual labels:  authorization
aarbac
An Automated Role Based Access Control .NET framework with T-SQL Query Parser which automatically parse select, insert, update, delete queries based on the logged in user role
Stars: ✭ 18 (+50%)
Mutual labels:  authorization
PyEditorial
A free, open-source Blog CMS based on the "Django" and "Editorial" HTML5 theme.
Stars: ✭ 178 (+1383.33%)
Mutual labels:  django-application
authorizer
Your data, your control. Fully open source, authentication and authorization. No lock-ins. Deployment in Railway in 120 seconds || Spin a docker image as a micro-service in your infra. Built in login page and Admin panel out of the box.
Stars: ✭ 770 (+6316.67%)
Mutual labels:  authorization
django-proxypay
Django Proxypay is a Django Framework application/library that facilitates the integration of your Django project with the Proxypay API.
Stars: ✭ 14 (+16.67%)
Mutual labels:  django-application
kibana-multitenant-proxy
A proxy behind nginx while before kibana (4.x, 5.x) to provide data isolation for different users
Stars: ✭ 25 (+108.33%)
Mutual labels:  authorization
pundit kit
Extension for pundit which allows to describe namespaces of policies in routes-like style
Stars: ✭ 12 (+0%)
Mutual labels:  authorization

Language grade: Python Codacy Badge Build Status Coverage Status Updates Code style: black

Python Versions Django Versions Database Window Functions

Let's Agree

Features

  • Terms versioning in "deque-style" with maxlen=1.
  • Per-Group Term association, per-User Term acceptance for each Group a user belongs to.
  • Max 1 query, either per request or per day for each logged-in user.
  • Multi-language ready.
  • Freedom for each user to withdraw consent at any time.

About

django-letsagreeis the result of an effort to follow the spirit of The EU General Data Protection Regulation (GDPR).

A logged in user can belong to one or more Groups.

If one or more Groups are associated with django-letsagree, all users that login as members of those Groups will be asked to provide their consent to the Terms related with each Group. This action, will be recorded in the database.

The Terms associated with a Group, can be updated with newer versions.

Such a decision will trigger again the mechanism which asks for the consent of each user before allowing any other operation on the site.

If the user does not provide consent, the following actions are only allowed:

  • Logout.
  • View and delete all instances of own consent provided.
  • View all Terms

Prerequisites

Installation

  1. pip install django-letsagree

  2. project/settings.py

    INSTALLED_APPS = [
        ...
        'letsagree.apps.LetsagreeConfig',
        ...
    ]
    
    MIDDLEWARE = [
        ...
        'letsagree.middleware.LetsAgreeMiddleware',  # Near the end of the list
        ...
    ]
  3. <project> is the name of the project that hosts django-letsagree

    project/settings.py:

    MIGRATION_MODULES = {
        'letsagree': '<project>.3p_migrations.letsagree',
    }
  4. Make sure LANGUAGES are properly set as explained in the Translation section. The default implementation will create as many fields as the number of LANGUAGES Django has set by default.

  5. project/urls.py:

    urlpatterns = [
            ...
            path('path/to/letsagree/', include('letsagree.urls')),
            ...
    ]
  6. Create the migrations:

    ./manage.py makemigrations letsagree
    ./manage.py migrate

Notes on installation

  • django-letsagree itself does not come with any migrations. It is recommended that you add migrations for its models in your project and avoid using the word migrations as the name of the folder.

    The relevant Django setting is MIGRATION_MODULES. In the above example, we store migrations inside <project>/<project>/3p_migrations.

Settings

Default Settings

LETSAGREE_CACHE = False
LETSAGREE_CSS = {}
LETSAGREE_JS = ()
LETSAGREE_LOGOUT_APP_NAME = ''  (Deprecated -> default value was 'admin')
LETSAGREE_LOGOUT_URL = 'admin:logout'
LETSAGREE_BROWSER_TITLE = ''
LETSAGREE_BORDER_HEADER = ''

Database queries

The middleware generates one database query per request in order to make sure that the user has agreed to all the terms related with the Group(s) he belongs to.

If LETSAGREE_CACHE = True, Django's Cache Framework will be used and only one database query will be generated by the middleware, every 24 hours.

LETSAGREE_CACHE is not enabled by default, because it exposes the unique id for each user by creating a cache record with key 'letsagree-<user id>'.

Tip: nshafer/django-hashid-field, is a library that obscures unique ids, without compromising their uniqueness.

Update: ericls/django-hashids is another non-intrusive library that proxies the field that is applied to.

Both libraries, however, are based on https://hashids.org/ which is not capable of encrypting sensitive data.

Translation

Watch your LANGUAGES!

Database

By default lestagree installs django-translated-fields to cater for translating the title, summary and content fields of the Term model. This library will create separate fields for each entry in the LANGUAGES list.

The first entry of this list is considered as the "default language". The relevant database field is marked as blank=False and it serves as a fallback value. This value is returned if an entry for the requested language does not exist.

All other fields that are related with the rest of the languages in the LANGUAGES list are marked as blank=True and can stay empty.

Although the LANGUAGE_CODE setting is not directly related with letsagree or django-translated-fields it is strongly recommended to match the first language in the LANGUAGES setting.

Example:

LANGUAGES = (('fr', 'French'), ('en', 'English'))
LANGUAGE_CODE = 'fr'

The model Term will include the following fields:

{
    'title_fr': {'blank': False},
    'title_en': {'blank': True},
    'summary_fr': {'blank': False},
    'summary_en': {'blank': True},
    'content_fr': {'blank': False},
    'content_en': {'blank': True},
}

Strings

All strings in django-letsagree are marked with one of the following ways which allow translation:

  • django.utils.translation.gettext_lazy('<string>')
  • {% trans "<string>" %}

Custom Form Assets

django-letsagree usesletsagree/pending.html template which extends admin/index.html. Through a FormView this template receives a Formset which includes all the Terms that should receive consent from the user.

LETSAGREE_CSS and LETSAGREE_JS when set, pass the relevant assets in the Media class of the Form that serves as the basis of the above mentioned Formset. The syntax is described in the relevant django documentation.

A good starting point could be the default css file provided by django-letsagree:

settings.py:

LETSAGREE_CSS = {'all': ('letsagree/letsagree.css',)}

Of course, one can completely override the templates.

In that case, bear in mind that if {{ empty_form }} is False, {{ form }} contains a formset.

Other settings

  • LETSAGREE_LOGOUT_URL: String that represents a namespaced URL.

    For example: 'admin:logout' is the default, it can be any string. If the url is not found, it fails silently resulting in the disappearance of the logout option.

  • LETSAGREE_BROWSER_TITLE: A title for the default template.

  • LETSAGREE_BORDER_HEADER: Text that will appear on the top left corner of the default template.

Permissions

It is your responsibility to assign every new user to a Group associated with django-letsagree. This group should at least include the delete_notarypublic permission in case a user whishes to revoke his consent.

If all permissions for django-letsagree models are delegated to a group, the below table illustrates what actions are allowed for user, with either is_staff == True or is_superuser == True:

Actions superuser own entries superuser other entries admin-user own entries admin-user other entries
view_term True True True True
add_term True True
change_term False False False False
delete_term False False False False
view_notarypublic True True True False
add_notarypublic False False
change_notarypublic False False False False
delete_notarypublic True False True False

Term changelist contents

Users who have permission to add a new term, are allowed to read all the available terms. Otherwise, each user can only read the terms related to the group that he or she belongs to.

New Term Version

If two instances of Term associate with the same Group, the instance saved-last is the latest version. All logged in users have to provide consent for this latest version, independently of any previous consent they may have or have not given for the Terms associated with this Group.

django-letsagree takes into account if a logged-in user has provided consent only for the latest version of each Term associated with the Groups he belongs to. If not, the user can only logout or visit django-letsagree admin page retaining the right to delete any instances of consent he has provided.

Tests

To run the test suite, you need:

  • Virtualenv with tox installed.
  • PostgreSQL, MariaDB/MySQL databases with the same user, password, database name.
  • The following environment variables set: TOX_DB_NAME, TOX_DB_USER, TOX_DB_PASSWD.

Unfortunatelly, the test suite is rather complicated. Sorry!

Coverage: Not tested

Changelog

1.1.8: Added support for Django-4.0 started testing for python-3.10, stopped testing for python-3.6 and python-3.7 (not supported by Django-4.0).

1.1.7: Added default_auto_field value to 'django.db.models.AutoField' for Django-3.2.

1.1.6: Fixed compatibility with Django-3.1

1.1.5: Fixed bug in LETSAGREE_LOGOUT_URL setting.

1.1.4: Deprecated LETSAGREE_LOGOUT_APP_NAME in favor of LETSAGREE_LOGOUT_URL

1.1.3: Locked to Django-3.0 until #39 is resolved

1.1.2: Added the ability to set a namespaced url in the "logout application name" setting.

1.1.1: AnonymousUser should not access letsagree urls (receives 404)

1.1.0: Refactored middleware for thread-safety

1.0.4: Added support for Django-3.0, dropped support for Django-2.1

1.0.3: Only users with add_perm can see all the Terms in changelist

1.0.2: Addressed codacy reports, updated readme, installed pyup, snyk

1.0.1: Added Travis, Coverage, LGTM, PyUp CI

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].