Создатель Python и пенсионер Гвидо Ван Россум был вынужден снова выйти на работу, на этот раз в Майкрософт. Нет, Гвидо сделал это не потому, что на 15 000 рублей (200 долларов) пенсии ему тяжело жить — в MS он устроился от скуки: талантливому инженеру не сидится без дела. Желаю всем нам в старости быть как Гвидо и плавно перехожу к разбору трех весьма полезных штуковин из питонячего мира.
zxcvbn-python
Как обычно проверяют пароли на сложность на бэкенде? Так, как мы все видели не раз в своей жизни — “пароль должен содержать не менее восьми символов, одну цифру, один спецсимвол и имя любимого персонажа Достоевского”. Конечно, такие минимальные требования к надежности пароля помогают задержать взломщика, но не всегда.
Например, если пароль технически состоит из нужного числа символов, но эти символы — имя и фамилия или части логина. Или в качестве пароля использована популярная комбинация символов, которую можно встретить во многих парольных словарях и таблицах хешей.
Библиотека zxcvbn-python производит реалистичную оценку пароля на сложность.
Как мы видим, либа считает примерную скорость, с которой пароль можно вскрыть путем перебора хэшей и методом прямого перебора через форму логина. А еще мы видим рекомендации по улучшению стойкости пароля и результаты поиска частей паролей в словаре, используемом взломщиками.
from zxcvbn import zxcvbn
results = zxcvbn('JohnSmith123', user_inputs=['John', 'Smith'])
print(results){
'password': 'JohnSmith123',
'score': 2,
'guesses': 2567800,
'guesses_log10': 6.409561194521849,
'calc_time': datetime.timedelta(0, 0, 5204)
'feedback': {
'warning': '',
'suggestions': [
'Add another word or two. Uncommon words are better.',
"Capitalization doesn't help very much"
]
},
'crack_times_display': {
'offline_fast_hashing_1e10_per_second': 'less than a second'
'offline_slow_hashing_1e4_per_second': '4 minutes',
'online_no_throttling_10_per_second': '3 days',
'online_throttling_100_per_hour': '3 years',
},
'crack_times_seconds': {
'offline_fast_hashing_1e10_per_second': 0.00025678,
'offline_slow_hashing_1e4_per_second': 256.78
'online_no_throttling_10_per_second': 256780.0,
'online_throttling_100_per_hour': 92440800.0,
},
'sequence': [{
'matched_word': 'john',
'rank': 2,
'pattern': 'dictionary',
'reversed': False,
'token': 'John',
'l33t': False,
'uppercase_variations': 2,
'i': 0,
'guesses': 50,
'l33t_variations': 1,
'dictionary_name': 'male_names',
'base_guesses': 2,
'guesses_log10': 1.6989700043360185,
'j': 3
}, {
'matched_word': 'smith123',
'rank': 12789,
'pattern': 'dictionary',
'reversed': False,
'token': 'Smith123',
'l33t': False,
'uppercase_variations': 2,
'i': 4,
'guesses': 25578,
'l33t_variations': 1,
'dictionary_name': 'passwords',
'base_guesses': 12789,
'guesses_log10': 4.407866583030775,
'j': 11
}],
}Ну и, конечно же, не забываем делать двухфакторку в своих проектах и блокируем аккаунт на Y минут после X неудачных попыток ввести пароль.
Notifiers
“А давайте у нас в этом случае будет приходить уведомление админам на телефон и в Slack” — все разработчики слышали вариации этой фразы от своих менеджеров. Дальнейшее развитие событий зависит от квалификации, мотивации и навыков разработчика. Либо дело ограничивается однострочным вызовом SMTP сервера, либо скачивается какая-то либа для посылки сообщений куда надо, либо пишется ООП комбайн с расширениями возможности посылки уведомлений любым мыслимым способом (включая голубиную почту).
Самые рьяные и мотивированные разработчики в мире не только уже выбрали самый сложный третий способ (доставка чего угодно куда угодно), но и оформили питонячий пакет на github. Встречаем notifiers — одна либа для доставки уведомлений сразу в кучу мест
Email (SMTP)
Gitter
Gmail
Hipchat
Join
Mailgun
Pagerduty
PopcornNotify
Pushbullet
Pushover
SimplePush
Slack (Webhooks)
StatusPage
Telegram
Twilio
Zulip
from notifiers import get_notifier
telegram = get_notifier('telegram')
telegram.notify(message='Hi!', token='TOKEN', chat_id=1234)Еще можно встроиться в логгер:
import logging
from notifiers.logging import NotificationHandler
log = logging.getLogger(__name__)
defaults = {
'token': 'foo',
'user': 'bar'
}
hdlr = NotificationHandler('pushover', defaults=defaults)
hdlr.setLevel(logging.ERROR)
log.addHandler(hdlr)
log.error('And just like that, you get notified about all your errors!')Tavern
Один менеджер скажет “тестирование” — миллионы разработчиков ему ответят “pytest”. Да, действительно, для многих программистов pytest стало синонимом слова “тестирование”. При этом абсолютно не важно, что и как мы тестируем — компоненты, интеграцию или поведение: этой либой можно заткнуть любую дырку.
Ничего ужасного в этом нет — pytest и правда позволяет это все делать. Берем эту либу, прикручиваем requests, пишем кучу всяких кейсов и операций с ответами и запросами к API — готово, мы получили комбайн по тестированию этого самого API.
Однако, при применении pytest для тестирования API код со временем начинает разрастаться, появляются обработчики заголовков, проверка ответов сервера, работа с куками и многие другие вещи. Те, кому приходилось поддерживать систему тестирования большого приложения на бэкенде, понимают, о чем идет речь.
Поэтому для тестирования API появился отдельный инструмент — tavern.
Tavern позволяет описывать тесты API в декларативной форме в формате YAML. И в эти декларативные сценарии уже заложено все, что вам нужно — вызовы сервера, обработка разных кодов ответа, заголовков, проверка данных в ответах.Растет гибкость, читаемость тестов и реюзабельность сценариев тестирования — а что нам еще нужно?
test_name: Get some fake data from the JSON placeholder API
stages:
- name: Make sure we have the right ID
request:
url: https://jsonplaceholder.typicode.com/posts/1
method: GET
response:
status_code: 200
json:
id: 1
save:
json:
returned_id: idНа сегодня все, прошлые питонячие радости смотрите по ссылке.
Atterratio
Я похожий на tavern велосипед один раз делал, мне если честно не особо понравилось как это работает. Недостаточно гибко, недостаточно прозрачно и толку мало так как тестами занимались программисты, и было привычнее и удобнее писать на питоне.