Комментарии 9
Идея хорошая, но мне кажется, что вы слишком уж много типов значений(и вариантов поведения) для ключа «post» сделали — рано или поздно начнутся ошибки.
IMHO стоит разбить на отдельные параметры с говорящими именами.
IMHO стоит разбить на отдельные параметры с говорящими именами.
На всякий случай: «post» просто был использован как пример. Ключ для хранения last_acces берется из request.method, который может быть любым (get, patch, post, put, delete).
Можно dict с примером данных?
IMHO стоит разбить на отдельные параметры с говорящими именами.
Можно dict с примером данных?
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.
Тогда добавлю еще один вариант: django-throttle.
Часть из приведенных умеет работать только с декораторами.
django-cache-throttle — только декоратор
django-rated требует redis (не имею ничего против, но это не всегда возможно)
django-ratelimit — упор на декораторы
django-break — декораторы, ip получается вот так: «return request.META['REMOTE_ADDR']», а там не всегда то, что надо
Проблема с декораторами всегда только одна: либо модификация чужих исходников, либо оборачивание чужой вьюхи своей (вместе с декоратором) и переопределение url в urls.py. Я думаю, что это не слишком удобно.
Часть из приведенных умеет работать только с декораторами.
django-cache-throttle — только декоратор
django-rated требует redis (не имею ничего против, но это не всегда возможно)
django-ratelimit — упор на декораторы
django-break — декораторы, ip получается вот так: «return request.META['REMOTE_ADDR']», а там не всегда то, что надо
Проблема с декораторами всегда только одна: либо модификация чужих исходников, либо оборачивание чужой вьюхи своей (вместе с декоратором) и переопределение url в urls.py. Я думаю, что это не слишком удобно.
Это понятно, просто мне кажется, что стоило бы в посте осветить готовые решения и то чем ваше лучше/отличается.
Добавил все найденное гуглом на djangopackages.
Да и usecase получается слишком узкий. Все таки, если не нужно использовать чужие вьюхи, то декораторы удобнее, ИМХО.
Возможно есть смысл также добавить декораторы.
Возможно есть смысл также добавить декораторы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django throttling