solovyov.net

Комментарии

3 min read · django, python, programming, blog, news

Как-то неожиданно пришло желание таки доделать всю функциональность, которую задумывал для подтверждения комментариев (подтверждение происходит тогда, когда незалогиненный, но существующий пользователь - проверяется по емейлу - пытается добавить новый комментарий) - логин сразу во время подтверждения.

Сначала я, в лучших традициях чукотской наивности, просто попытался добавить вызов функции залогинивания после подтверждения правильности комментария и чистоты помыслов его автора, но не тут-то было! Джанга мне быстренько рассказала, кто здесь хозяин и где собственно у пользователя свойство backend?

Я понял, что двумя пальцами и асфальтом не обойдусь и пошёл читать доку. После беглого просмотра жалкой пары абзацев по предыдущей ссылке я уловил, что мне надо в любом случае применить функцию authenticate, которая и установит пользователю искомое свойство. В надежде, что я обойдусь без написания своего бекенда, решил порыться в гугле - и мои опасения, в который раз, оказались обоснованными. :-) Существует тикет, как раз по моему вопросу, закрытый больше года назад Малькольмом Трединником с объяснением: “нечего голову морочить, читайте доки и пишите бекенды, это несложно”.

На самом деле всё оказалось не просто несложно, а вообще просто бесплатно. ;-) Написание первоначальной версии бекенда (только для подтверждения комментариев) заняло у меня порядка 5 минут с ловлей блох, а доработка до более модной версии, которая теперь работает и для активации пользователя (активировался - и уже залогинен :-) заняла ещё порядка 10 минут с обдумыванием, а как же будет лучше это реализовать.

Получился небольшой кусочек кода, который к тому же ещё обладает способностью к лёгкому расширению. :-) На самом деле бекенд - это просто небольшой класс, который должен иметь два метода - authenticate, для проверки валидности пришедших мандатов1, и get_user, для получения юзера и добавления его к объекту запроса (т.е. к request).

get_user, использующийся с джанговской стандартной модельюUser (а я в блоге только ей и пользуюсь), всегда выходит одинаковый (про это немного написано в последнем абзаце), потому говорить тут не о чем. А вот authenticate получился достаточно интересным, на мой взгляд: он вызывает динамически (хе-хе, использование getattr даёт право написать это слово) необходимый метод для совершения действа (например, активирования пользователя) - почему я и написал про лёгкую расширяемость.

А теперь два слова про однообразный get_user. На самом деле, когда я писал сам бекенд, я понял только, зачем нужен authenticate, и чтоб разобраться с get_user (не хотелось опубликовывать куцый пост ;-), мне пришлось рыться в джанговском contrib.auth. Внимательное чтение легко объяснило, что к чему, но я заметил очень неприятную штуку - кучу жёстко закодированных вещей. Собственно, у меня самого такое встречается (и мне откровенно неудобно такое отсылать в репозиторий, но время часто не резиновое, и общее красивое решение некогда делать), но тут… В общем, у меня роятся мысли это поправить всё, вроде не выглядит сложным. Надеюсь, соберусь это сделать (и для диплома полезно будет ;-).


  1. не могу подобрать русского перевода для слова “credentials” - Лингво из адекватных предлагает только “мандаты”, но меня и оно как-то не устраивает. В общем, сочетания логин и пароль, или openid, или, в данном случае, активационного ключа. ↩︎

If you like what you read — subscribe to my Twitter, I always post links to new posts there. Or, in case you're an old school person longing for an ancient technology, put a link to my RSS feed in your feed reader (it's actually Atom feed, but who cares).

Other recent posts

Server-Sent Events, but with POST
ngrok for the wicked, or expose your ports comfortably
PostgreSQL collation
History Snapshotting in TwinSpark
Code streaming: hundred ounces of nuances