Django throttling

[@oxyum]

Идея хорошая, но мне кажется, что вы слишком уж много типов значений(и вариантов поведения) для ключа «post» сделали — рано или поздно начнутся ошибки.

IMHO стоит разбить на отдельные параметры с говорящими именами.

[@lilo_panic]

На всякий случай: «post» просто был использован как пример. Ключ для хранения last_acces берется из request.method, который может быть любым (get, patch, post, put, delete).

IMHO стоит разбить на отдельные параметры с говорящими именами.

Можно dict с примером данных?

[@oxyum]

DJANGO_THROTTLING = {
    '__default__': {
        'all': 1000,
        'post': {'redirect': '/'},
        'get': {'callable': 'helpers.trash.my_callback'},
        'congestion': 'forum.views.congestion',
    },
    'django.contrib.admin.options.change_view': {
        'all': None,
        'post': False,
        'put': {'callable': my_callback_fun},
        'uri': '/admin/forum/post/23/',
    },

}

Тут я создал "__default__"-сущность, ибо лично я не люблю, когда на одном уровне конфига есть разные логические сущности и создал dict для «сложных» типов обработчиков. Это так же позволяет передавать прямо callable объекты, а не только строки, хотя для settings оно скорее всего излишне, а то и вредно.

Как вариант, можно сделать вариант «int|bool|str», а в str всегда указывать тип аргумента:

{
    'all': 'view:my_view',
    'get': 'redirect:/',
    'put': 'reverse_redirect:throttle-uri-name',
    'post': 'callable:my_func',
}

ну и т.д.

То есть тут различие только в синтаксисе — или парсим строку, или получаем готовый dict.

[@lilo_panic]

Спасибо. Вариант с dict правильней, пожалуй. Подумаю над фиксом. Заодно, если реализовать такой вариант, можно будет передавать кастомные для method_type congestion handler'ы. Правда, не совсем понятно нужно ли это (поскольку callback и так получает все необходимое, тот же request).

[@dizballanze]

Уже существуют готовые решения:
django-brake
django-cache-throttle
django-rated
django-ratelimit

[@lilo_panic]

Тогда добавлю еще один вариант: django-throttle.
Часть из приведенных умеет работать только с декораторами.

django-cache-throttle — только декоратор
django-rated требует redis (не имею ничего против, но это не всегда возможно)
django-ratelimit — упор на декораторы
django-break — декораторы, ip получается вот так: «return request.META['REMOTE_ADDR']», а там не всегда то, что надо

Проблема с декораторами всегда только одна: либо модификация чужих исходников, либо оборачивание чужой вьюхи своей (вместе с декоратором) и переопределение url в urls.py. Я думаю, что это не слишком удобно.

[@dizballanze]

Это понятно, просто мне кажется, что стоило бы в посте осветить готовые решения и то чем ваше лучше/отличается.

[@lilo_panic]

Добавил все найденное гуглом на djangopackages.

[@dizballanze]

Да и usecase получается слишком узкий. Все таки, если не нужно использовать чужие вьюхи, то декораторы удобнее, ИМХО.
Возможно есть смысл также добавить декораторы.