idec.talks Re: Эталонная реализация idec 12/08/19 03:51 UTC Andrew Lobanov to vit01

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
vit01> Слабая валидация POST данных. Особенно на тех же файловых эхах

Непонятно что именно не так =)

vit01> Способ хранения индексов вместе с файлами в фэхах меня тоже немного удивил. Можно попробовать в качестве атаки ввести фэху index и загрузить там файл с названием другой фэхи, тем самым легко затерев всё содержимое последней.

Можешь привести пример?

vit01> Мои пожелания:
vit01> 1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"

На боевой реализации конфиги вообще в БД будут

vit01> Уже часто начал замечать, что при таком подходе гораздо проще делать бэкапы и отделять файлы репозитория от изменяемых файлов.
vit01> // все блэклисты и изменяемые конфиги полностью туда

В БД всё.

vit01> К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

Зачем ускорять развёртывание эталонной реализации. Это же по факту POC.

vit01> 2. Объединить cli-скрипты в единый интерфейс и запускать вроде
vit01> ====
vit01> idec.py run
vit01> idec.py points add Vasya
vit01> idec.py stats -f ... -t ...
vit01> idec.py stats --help
vit01> ====

Нет смысла. Это усложнит чтение исходного кода.

vit01> 3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один
vit01> https://docs.python.org/3/library/argparse.html

Про это я пока у Лутца не читал =)

vit01> 4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

Нет смысла в эталонной реализации. Как и вебморда не нужна.