django-lock-tokens is a Django application that provides a locking mechanism to prevent concurrency editing.

It is not user-based nor session-based, it is just token based. When you lock a resource, you are given a token string with an expiration date, and you will need to provide this token to unlock that resource.

The application provides some useful functions to handle this token mechanism with sessions if you want to, and a REST API (with a javascript client for it) to deal with lock tokens without sessions.

Here is a non exhaustive list of the features coming with this token-based approach, to help you choose django-lock-tokens (or not!) over other concurrent edition preventing solutions:

• No need to modify your models to use the locking mechanism : you don't "pollute" your datamodel with "non-data" fields. This also means you can use the locking mechanism on third party models that cannot be modified
• No need to use sessions (but you can still use it if you want to)
• Ability to check if an object is locked BEFORE trying to modify it
• Rest API (+ javascript client to use it) out-of-the-box
• Admin interface integration

1. Requirements
2. Install
3. TL;DR
4. How it works
5. LockableModel proxy
6. LockableModelAdmin for admin interface
7. Session-based usage: lock_tokens.sessions module
8. Session-based usage: lock_tokens.decorators module
9. REST API
10. REST API Javascript client
11. Settings
12. Tests

• Python (2.7, 3.3, 3.4, 3.5)
• Django (1.8, 1.9, 1.10, 1.11, 2.0, 2.1)

1. Run pip install django-lock-tokens
2. Add lock_tokens to your INSTALLED_APPS setting. As django-lock-tokens uses the contenttypes framework, make sure it is also available in your INSTALLED_APPS setting:

INSTALLED_APPS = [
    ...
    'django.contrib.contenttypes',
    ...
    'lock_tokens.apps.LockTokensConfig',
]

3. Run python manage.py migrate from the root of your django project to install the lock tokens model.
4. If you want to use the LockableAdmin and all the session-based functionalities, make sure you have enabled a session middleware in your settings, for example:

MIDDLEWARE_CLASSES = (
    ...
    'django.contrib.sessions.middleware.SessionMiddleware',
    ...
)

5. If you want to use the REST API, include lock_tokens.urls with the correct namespace in your urls.py like this (it is mandatory if you want to use the LockableModelAdmin):

urlpatterns = [
  ...
  url(r'^lock_tokens/', include('lock_tokens.urls', namespace='lock-tokens')),
  ...
]

After having completed previous steps, using the locking mechanism in your views is as simple as this:

from django.http import HttpResponseForbidden
from lock_tokens.exceptions import AlreadyLockedError, UnlockForbiddenError
from lock_tokens.sessions import check_for_session, lock_for_session, unlock_for_session

from my_app.models import MyModel


def view_with_object_edition(request):
    """This view locks the instance of MyModel that is to be edited."""
    # Get MyModel instance:
    obj = MyModel.objects.get(...)
    try:
        lock_for_session(obj, request.session)
    except AlreadyLockedError:
        return HttpResponseForbidden("This resource is locked, sorry !")
    # ... Do stuff
    return render(...)


def view_that_saves_object(request):
    """This view locks the instance of MyModel that is to be edited."""
    # Get MyModel instance:
    obj = MyModel.objects.get(...)
    if not check_for_session(obj, request.session):
        return HttpResponseForbidden("Cannot modify the object, you don't have the lock.")
    # ... Do stuff
    unlock_for_session(obj, request.session)
    return render(...)

Or use it directly in your Django templates to handle locking on the client side:

{% load lock_tokens_tags %}
{% lock_tokens_api_client %}
...
<script type="text/javascript">
    window.addEventListener('lock_tokens.clientready', function () {
        LockTokens.lock(...);
        ...
        LockTokens.unlock(...);
    });
</script>

To avoid concurrency editing, django-lock-tokens provides some interfaces to lock and check lock on any model instance before changing it (including third party model instances). This is handled via an internal model (LockToken). There can be only one LockToken instance per model instance.

The lock token lifecycle is the following:

1. When a lock is created for an object by an entity, it is valid for a certain amount of time. The entity is given a lock token key (a string) that it must hold to perform actions with valid lock required. A new LockToken instance is created in database, after having deleted a potential expired instance in database.
2. If the entity that holds the lock token key no longer needs the lock on the object, it can unlock this object by providing the lock token key. The LockToken instance is then removed from database.
3. The entity that holds the lock token key can also renew the lock token by providing the lock token key.
4. If the lock token is not renewed until the expiration time, it becomes expired, but stays in database until a new lock is created on this instance (or the entity that holds the lock token key deletes it).

So to use this mechanism correctly, you should require a valid lock token key and renew the lock in any method where an object is saved and you want to prevent concurrency editing. Based on the 4 previous points, we can see that there can be 3 cases for a lock token key:

1. The lock token key has a corresponding lock token in database, and it has not expired.
2. The lock token key has a corresponding lock token in database, but it has expired.
3. The lock token key has no correponding lock token in database for the object.

For case 1, it is ok to save the object and then unlock the object by deleting the lock token. The token key is still VALID.

For case 2, the lock has expired but no other entity has created a lock on the object in the meantime. So it is still ok to save the object as it will not overwrite any changes. The token key is still VALID.

In case 3, it means that the lock token created by the entity has expired, and that another entity has taken a lock on the object in the meantime and could have done some changes on it. So it is not ok to save changes. The token key is INVALID.

Here is an example to understand the case 3:

1. Alice takes a lock on an object and opens up its editing interface. A ``LockToken`` instance ``lt1`` is created in database, and Alice is given a lock token key
2. Alice walks away from her computer, the lock expires. ``lt1`` is still in database
3. Bob takes a lock on the same object. ``lt1`` is deleted from database, and a new ``LockToken`` instance ``lt2`` is created
4. Bob edits the object in the interface, clicks save. The object is modified and the lock is released. ``lt2`` is deleted. The object has no longer any lock in database
5. Alice returns, clicks save. The lock token key she holds has become invalid, so she gets an error.

This example shows how it is important to require a VALID lock token key to prevent concurrency editing.

To make one of your models lockable, use the LockableModel class. LockableModel is just a Django proxy model, which simply provides additional locking methods to your models.

So you can either make your models inherit from LockableModel:

from lock_tokens.models import LockableModel

class MyModel(LockableModel):
    ...

obj = MyModel.get(...)
token = obj.lock()

or you can simply use it as a proxy on a given model instance:

from lock_tokens.models import LockableModel

from my_app.models import MyModel

obj = MyModel.get(...)
token = LockableModel.lock(obj)

This can be useful if you don't want to expose the locking methods for your models everywhere, or if you want to lock resources that come from a third party application.

Note that as LockableModel is just a proxy model, make your models inherit from it won't change their fields so there will be no additional migrations required.

Additionally, if your model inherits from LockableModel, the objects Manager has a specific method that allows you to get and lock a model like so:

>>>obj, token = MyModel.get_and_lock(...<usual get arguments>)

If you already overrided the default objects manager with a custom one and that you want to get this method available, make your custom manager inherit from lock_tokens.managers.LockableModelManager.

Locks the given object, or renew existing lock if the token parameter is provided.

Returns a dict containing a token a its expiration date.

Raises a lock_tokens.exceptions.AlreadyLockedError if the resource is already locked, and a lock_tokens.exceptions.InvalidToken if the specified token is invalid.

Example:

def test(myObject):
    try:
        token = myObject.lock()
    except AlreadyLockedError:
        print "This object is already locked"
    return token


>>>token = test(obj)
{"token": "9692ac52a27a40308b82b49b77357c97", "expires": "2016-06-23 09:48:06"}
>>>test(obj)
"This object is already locked"
>>>test(obj, token['token'])
{"token": "9692ac52a27a40308b82b49b77357c97", "expires": "2016-06-23 09:48:26"}

Unlocks the given object if the provided token is correct.

Raises a lock_tokens.exceptions.UnlockForbiddenError

Returns a boolean that indicates whether the given object is currently locked or not.

Returns a boolean that indicates if the given token is valid for this object. Will also return True with a warning if the object is not locked (lock expired or no lock).

If you want to make the admin interface lock-aware, and lock objects that are edited, simply make your ModelAdmin class inherit from LockableModelAdmin:

from lock_tokens.admin import LockableModelAdmin
from django.contrib import admin

from my_app.models import MyModel

class MyModelAdmin(LockableModelAdmin):
    ...

admin.site.register(MyModel, MyModelAdmin)

With this, when accessing a given instance of MyModel from the admin interface, it will check that the instance is not locked. If it is not, it will lock it. If it is, then there will be a warning message displayed to inform that the object cannot be edited, and the saving buttons will not appear. And if despite this, the change form is sent, it will raise a PermissionDenied exception so you will get a HTTP 403 error.

If you want to override the change_form_template, but still make sure the lock will be released when leaving the page without saving, don't forget to add the admin_lock_handler template tag. This template tag needs 4 arguments: the application name of the object, the model name of the object, the object id and the lock token key. So don't forget to add those (especially the lock token) into your template context if you also override the change_view method.

Example to add the template tag to your custom template if you don't override change_view:

...
{% load lock_tokens_tags %}
...
{% if lock_token %}
  {% admin_lock_handler opts.app_label opts.model_name original.id lock_token %}
{% endif %}

In most cases, it will be the easiest way to deal with lock tokens, as you won't need to handle them at all.

Lock an object in the given session. This function will try to lock the object, and if it succeeds, it will hold the token value in a session variable.

There is a force_new optional parameter that you can set to True if you want to force a new lock generation without using a potentially existing token key stored in session. This is to be used with caution (i.e. exclusively in methods that only read the object, not in methods that save it) as it could lead to a potential overwriting if the session holds an invalid token. To sum up: do not set this parameter to True unless you are sure of what you are doing!

Raises a lock_tokens.exceptions.AlreadyLockedError if the resource is already locked, and a lock_tokens.exceptions.InvalidToken error if the session holds an invalid token.

Unlocks an object in the given session.

Raises a lock_tokens.exceptions.UnlockForbiddenError if the session does not hold the lock on the object.

Check if an object has a valid lock in the given session.

Returns True if the session holds a valid lock (even if it has expired), and False if the session holds an invalid lock or no lock.

This module provides view decorators for common use cases.

Locks an object before executing view, and keep lock token in the request session. Does not unlock it when the view returns.

Arguments:

• model: the concerned django Model
• get_object_id_callable: a callable that will return the concerned object id based on the view arguments

Example:

from lock_tokens.decorators import locks_object

@locks_object(MyModel, lambda request: request.GET.get('my_model_id'))
def myview(request):
    # In this example the view will lock the MyModel instance with the id
    # provided in the request GET parameter my_model_id
    ...

@locks_object(MyModel, lambda request, object_id: object_id)
def anotherview(request, object_id):
    # In this example the view will lock the MyModel instance with the id
    # provided as the second view argument
    ...

Locks an object before executing view, and keep lock token in the request session. Hold lock until the view is finished executing, then release it.

Arguments:

• model: the concerned django Model
• get_object_id_callable: a callable that will return the concerned object id based on the view arguments

See examples for locks_object.

If you want to use locking mechanism from outside your views, there is a simple HTTP API to handle tokens. It does not use sessions at all, so you need to handle the tokens yourself in this case.

Here are the different entry points, where <app_label> is the name of the application of the concerned model, <model> is the name of the model, <object_id> is the id of the cmodel instance, and <token> is the lock token value.

Locks object. Returns a JSON response with "token" and "expires" keys.

Returns a 404 HTTP error if the object could not be found.

Returns a 403 HTTP error if the object is already locked.

Returns a JSON response with "token" and "expires" keys.

Returns a 404 HTTP error if the object could not be found.

Returns a 403 HTTP error if the token is incorrect.

Renews the lock on the object. Returns a JSON response with "token" and "expires" keys.

Returns a 404 HTTP error if the object could not be found.

Returns a 403 HTTP error if the token is incorrect.

Unlocks object.

Returns a 404 HTTP error if the object could not be found.

Returns a 403 HTTP error if the token is incorrect.

The application includes a javascript client to interact with the API. To enable it, simply add the following lines to your template, somewhere in the <body> section

{% load lock_tokens_tags %}
{% lock_tokens_api_client %}

Don't forget to include the REST API urls with the correct namespace as described in section 1, otherwise it won't work.

Adding those lines in your template will create a variable named LockTokens, and emit a lock_tokens.clientready event when it is available in the javascript scope. This object has the following methods (parameters are self-describing):

Locks the corresponding object. When the call to the API is completed, calls the callback method with a lock_tokens.Token instance as an argument, or null if the API request failed.

NB: The LockTokens handles the tokens for you, so you don't need to read API responses and/or store tokens yourself.

Add an existing token to the LockTokens registry. This method is useful for example when you want to handle on client side a lock that has been set on the server side. You must provide the token string in addition to other parameters, the client will make a call to the API to ensure the token is valid and get its expiration date. Calls the callback method with a lock_tokens.Token instance as an argument, or null if the registration failed.

Locks the corresponding object. When the call to the API is completed, calls the callback method with a boolean that indicates whether the API request has succeeded. Note that this method can be called only on an object that has been locked or registered as locked by the LockTokens object.

Holds a lock on the corresponding object. It is like the lock method, except it renews the token each time it is about to expire. A call to unlock will stop the lock holding.

Unlocks all registered objects. Calls callback with no arguments when unlocking of every objects is done.

You can override lock_token default settings by adding a dict named LOCK_TOKENS to your settings.py like so:

LOCK_TOKENS = {
    'API_CSRF_EXEMPT': True,
    'DATEFORMAT': "%Y%m%d%H%M%S",
    'TIMEOUT': 60,
}

The validity duration for a lock token in seconds. Defaults to 3600 (one hour).

The format of the expiration date returned in the token dict. Defaults to "%Y-%m-%d %H:%M:%S %Z"

A boolean that indicates whether to deactivate CSRF checks on the API views or not. Defaults to False.

To run tests simply run from the root of the repository:

source <YOURVIRTUALENV>/bin/activate
(myenv) $ pip install tox
(myenv) $ tox

Tools used in rendering this package:

• Cookiecutter
• cookiecutter-djangopackage