django-anysign

django-anysign is a Django application to manage online signature in a generic way.

Its goal is to provide a consistent API whatever the signature implementation. So that, using django-anysign, you can easily switch from one signature backend to another, or use several backends at once.

Project status

django-anysign is under active development. The project is not mature yet, but authors already use it! It means that, while API and implementation may change (improve!) a bit, authors do care of the changes.

Also, help is welcome! Feel free to report issues, request features or refactoring!

Contents

Install

django-anysign is open-source software, published under BSD license. See License for details.

If you want to install a development environment, you should go to Contributing documentation.

Prerequisites

  • Python [1] 2.7, 3.3 or 3.4. Other versions may work, but they are not part of the test suite at the moment.

As a library

In most cases, you will use django-anysign as a dependency of another project. In such a case, you should add django-anysign in your main project’s requirements. Typically in setup.py:

from setuptools import setup

setup(
    install_requires=[
        'django-anysign',
        #...
    ]
    # ...
)

Then when you install your main project with your favorite package manager (like pip [2]), django-anysign will automatically be installed.

Standalone

You can install django-anysign with your favorite Python package manager. As an example with pip [2]:

pip install django-anysign

Check

Check django-anysign has been installed:

python -c "import django_anysign;print(django_anysign.__version__)"

You should get django_anysign‘s version.

References

[1]https://www.python.org/
[2](1, 2) https://pypi.python.org/pypi/pip/

Configure

Here is the list of settings used by django-anysign.

INSTALLED_APPS

There is no need to register django-anysign application in your Django’s INSTALLED_APPS setting.

ANYSIGN

The settings.ANYSIGN is a dictionary that contains all specific configuration for django-anysign.

Example from the Demo project:

ANYSIGN = {
    'BACKENDS': {
        'dummysign': 'django_dummysign.backend.DummySignBackend',
    },
    'SIGNATURE_TYPE_MODEL': 'django_anysign_demo.models.SignatureType',
    'SIGNATURE_MODEL': 'django_anysign_demo.models.Signature',
    'SIGNER_MODEL': 'django_anysign_demo.models.Signer',
}
BACKENDS

A dictionary where:

  • keys are backend codes, i.e. machine-readable names for backends. These keys are typically stored in the database as django_anysign.models.SignatureType.signature_backend_code.
  • values are Python path to import backend’s implementation, typically a class.

See also get_signature_backend().

SIGNATURE_TYPE_MODEL

The Python path to import the SignatureType model.

SIGNATURE_MODEL

The Python path to import the Signature model.

SIGNER_MODEL

The Python path to import the Signer model.

Models

django-anysign presumes digital signature involves models in the Django project: one to store the signatures, another to store signers, and one to store backend specific options.

That said, django-anysign does not embeds concrete models: it provides base models you have to extend in your applications. This design allows you to customize models the way you like, i.e. depending on your use case.

Minimal integration

Here is the minimal integration you need in some models.py:

import django_anysign


class SignatureType(django_anysign.SignatureType):
    pass


class Signature(django_anysign.SignatureFactory(SignatureType)):
    pass


class Signer(django_anysign.SignerFactory(Signature)):
    pass

The example above is taken from django-anysign‘s Demo project.

SignatureType

Signature

Here is what you get in the Demo project:

Signer

Here is what you get in the Demo project:

Backends

django-anysign‘s signature backend encapsulates signature workflow and integration with vendor specific implementation.

Note

The backend API is quite experimental. This document deals with both vision (concepts) and current implementation (which may improve).

Scope of a backend

A signature backend is typically known by models and views. They use the backend to perform vendor-specific operations. The backend contains vendor-specific implementation that has to be shared with several consumers such as models and views.

A signature backend also typically knowns the workflows. So it should be helpful for URL resolution.

django-anysign’s SignatureBackend

Here is the current implementation of base backend.

django-dummysign’s SignatureBackend

Here is the demo signature backend implementation provided by django-dummysign.

import logging

import django_anysign


logger = logging.getLogger(__name__)


class DummySignBackend(django_anysign.SignatureBackend):
    def __init__(self):
        super(DummySignBackend, self).__init__(
            name='DummySign',
            code='dummysign',
        )

    def create_signature(self, signature):
        """Register ``signature`` in backend, return updated object.

        As a dummy backend: just emit a log.

        """
        signature = super(DummySignBackend, self).create_signature(self)
        logger.debug('[django_dummysign] Signature created in backend')
        return signature

Views

At the moment, django-anysign does not provide views or generic views. But this feature is part of the Vision...

Loading

Since django-anysign does not provide concrete Models, and models are configured in settings, here are tools to load models and backends.

get_signature_backend

get_signature_type_model

get_signature_model

get_signer_model

Demo project

Demo folder in project’s repository [1] contains a Django project to illustrate django-anysign usage. It basically integrates django-dummysign in a project.

Examples in the documentation are imported from the demo project.

Feel free to use the demo project as a sandbox. See Contributing for details about development environment setup.

Notes & references

[1]https://github.com/novapost/django-anysign/tree/master/demo/

About django-anysign

This section is about the django-anysign project itself.

Vision

django-anysign provides conventions and base resources to implement digital signature features within a Django project.

django-anysign‘s goal is to provide a consistent API whatever the signature implementation. This concept basically covers the following use cases:

  • plug several signature backends and their specific workflows into a single website.
  • in a website using a single signature backend, migrate from one backend to another with minimum efforts.
  • as a developer, implement bindings for a new signature service vendor.

django-anysign presumes the following items are generally involved in digital signature features:

  • models. Such as signature, signer and signature type (backend options).
  • workflows. They usually start with the creation of a document to sign (setup a signature, assign signers, choose a backend). They usually end when the document has been signed by all signers. Steps between “start” and “end” typically vary depending on the vendor signature service.
  • views. Most signature workflows use similar views, such as “create signature”, “sign document”, “signer processed document” or “API callback”. Of course, the implementation and order vary depending on the vendor signature service. But some bits are generic.

django-anysign does not include vendor-specific implementation. Third-party projects do. And they can be based on django-anysign. So as a developer, you are likely to discover django-anysign via these vendor-specific projects. See Alternatives and related projects for details about third-party projects.

django-anysign is a framework. It does not provide all-in-one solutions. You may have to implement some things in your Django project. django-anysign tries to make this custom code easier to imagine and write, using conventions, utilities and base classes.

License

Copyright (c) 2014, Benoît Bryon. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of django-anysign nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Authors & contributors

Maintainer: Benoît Bryon <benoit@marmelune.net>, as a member of the PeopleDoc [1] team: https://github.com/novapost/

Developers: https://github.com/novapost/pydocusign/graphs/contributors

Notes & references

[1]http://www.people-doc.com

Changelog

This document describes changes between each past release. For information about future releases, check milestones [1] and Vision.

0.1 (2014-08-11)

Initial release.

  • Introduced base model SignatureType and base model factories SignatureFactory and SignerFactory.
  • Introduced base backend class SignatureBackend.
  • Introduced loaders for custom models and backend: get_signature_backend_instance, get_signature_type_model, get_signature_model and get_signer_model.

Notes & references

[1]https://github.com/novapost/django-anysign/milestones

Contributing

This document provides guidelines for people who want to contribute to the django-anysign project.

Create tickets

Please use django-anysign bugtracker [1] before starting some work:

  • check if the bug or feature request has already been filed. It may have been answered too!
  • else create a new ticket.
  • if you plan to contribute, tell us, so that we are given an opportunity to give feedback as soon as possible.
  • Then, in your commit messages, reference the ticket with some refs #TICKET-ID syntax.

Use topic branches

  • Work in branches.
  • Prefix your branch with the ticket ID corresponding to the issue. As an example, if you are working on ticket #23 which is about contribute documentation, name your branch like 23-contribute-doc.
  • If you work in a development branch and want to refresh it with changes from master, please rebase [2] or merge-based rebase [3], i.e. do not merge master.

Fork, clone

Clone django-anysign repository (adapt to use your own fork):

git clone git@github.com:novapost/django-anysign.git
cd django-anysign/

Usual actions

The Makefile is the reference card for usual actions in development environment:

  • Install development toolkit with pip [4]: make develop.
  • Run tests with tox [5]: make test.
  • Build documentation: make documentation. It builds Sphinx [6] documentation in var/docs/html/index.html.
  • Release django-anysign project with zest.releaser [7]: make release.
  • Cleanup local repository: make clean, make distclean and make maintainer-clean.

See also make help.

Notes & references

[1]https://github.com/novapost/django-anysign/issues
[2]http://git-scm.com/book/en/Git-Branching-Rebasing
[3]http://tech.novapost.fr/psycho-rebasing-en.html
[4]https://pypi.python.org/pypi/pip/
[5]https://pypi.python.org/pypi/tox/
[6]https://pypi.python.org/pypi/Sphinx/
[7]https://pypi.python.org/pypi/zest.releaser/

Indices and tables