Рефакторинг библиотек
Потихоньку рефакторю свои библиотеки.
django-account более не использует базу данных для хранения кодов-активации. К сожалению, нету настроения писать, как оно работает… в общем, без базы оно работает ))) Посмотрите ченжлог — там по коду понятно ) Даже тесты написал. Это у меня редкость.
django-captcha наоборот теперь использует базу данных! Ранее я хранил связку (хэш каптчи, ответ) в сессии и использовал для этого грязный? хак threadlocals. Сегодня утром чё-то подумал, что это не камильфо, и переписал аппликуху — теперь эти связки в базу сохраняются. Идеальным решением я вижу сохранять в memcached или в то, к чему подключен стандартный кэш джанги. Пока не хочу на этом заморачиваться.
Далее на очереди пофиксать django-flash. Хрюндель матерился, что оно мильон сессии генерит.
Вот такой вот УГ-пост получился :o) С наступающим, товарищи.
UPD: django-flash изменил. Теперь оно хранит инфу в кукисах и не юзает threadlocals хак ) Ну и соотвественно с сессиями никак не работает и не генерит их пачками, хотя я даже и не выяснял, в чём там проблема была.
Comments
Сегодня праздник какой то.. я две аппы написал, ты две пофиксил..
Не, threadlocals юзался, чтобы per anus протащить request в те части системы, где request был недоступен по дизайну. А то, какой поток, что обрабатывал, было неважно т.к. мы складировали нужную информацию в сессиию (фактически в БД), данные которой перечитываются при каждом новом запросе.
Протестировал на боевом сервере новую версию django-flash. Полёт нормальный!
Старый django-flash наделал 365 тыщ сессий, весом в 110 мб )) Заморал ты свою репутацию Lorien..
а, и print’ы не забудь стереть
Зачем капчи в базе хранить? Почему просто не вычислять хеш по ответу.
Мне нужно сформировать в шаблоне hidden-поле с хэшем + img тэг с адресом каптчи, в этом адресе, естественно, я не могу указать ответ, только хэш. Далее view, которая будет обрабатывать URL каптчи должна как-то отобразить картинку, для этого она и лезет в БД, чтобы по хэшу узнать ответ.
Все верно. Но есть другой подход: на сервере формируем хеш как : md5(“секретное слово”+”Текст на капче”+”уникальный индентификатор события”)
клиенту выдаем капчу и текст. По сабмиту на сервере:
еще раз вычисляем хеш и сверяем.
Неа, не понял. Пример opensource проекта, где это реализовано есть?
К примеру на питоне это так:
Мы хотим сделать капчку на добавление 13ого комента к 18ому посту.
import md5
secKey = ‘abcd’
actionKey = ‘addComment_13toPost18’
captionText = ‘TipoCapcha’
hashKey = md5.md5(secKey+actionKey+captionText).hexdigest()
Пользователю в ходден полях показываем все, кроме secKey. Его потом используем для сверки.
Как сверять показывать?
Проблема в том, чтобы не показывать captionText в голом виде, иначе робот просто прочитает его и никакой OCR даже не потребуется.
Вы не туда смотрите. Я вам показываю решение проверки капчи без использования БД. Как сделать из текста картинку это уже другая задача, как по мне более сложная, но готовые решения на эту тему имеются.
Как сверять. Во вьюху к вам приходит уже акшен кей, введенная пользователем капча и свормированый нами хеш:
actionKey = ‘addComment_13toPost18’
captionText = ‘TipoCapcha’
hashKey = ‘XXXXxxxXXXXxxxXXXX’
нам необходимо еще раз посчитать хеш и сравнить его с переданным из пользовательской формы. Секретный ключ мы и так знаем
secKey = ‘abcd’
checkKey = md5.md5(secKey+actionKey+captionText).hexdigest()
итого, если checkKey и hashKey равны, то капча введена верно
Я использую БД не для того, чтобы проверять каптчу, а для того, чтобы иметь возможность получить текст каптчи по её хэшу при построении картинки.
Похоже на то, что мы друг друга не понимаем. Обещаю уже на своем блоге бахнуть ответным постом, а сюда ссылку коментнуть.
Да, было бы неплохо )
Спасибо за django-flash. Очень пригодилось :) И django-captcha скоро буду мучать, а django-account изучаю код. :)
Главное, про баги пиши, если найдёшь )