но если мы получаем post от доверенного источника (чисто токены), то так вполне можно сделать
Нет. XSS делать никогда не стоит. safe не предназначен для рендеринга json. Со стороны django было большой глупостью назвать safe фильтр, который делает крайне опасные вещи.
Кстати, как вы контролируете, что получаете post от доверенного источника?
Фильтр safe отключает экранирование символов, чтобы JSON остался валидным.
Фильтр safe действительно отключает экранирование, но использовать его в таких целях не стоит, потому что это верный путь к xss: ?a=</script><script>alert(1)</script>
Также совершенно непонятно как будет работать 'post_data': request.body, потому что request.body это bytes, соответственно рендерится он будет как post: b''.
Также django по-умолчанию требует csrf токен для non-safe методов, к которым в том числе относится post, однако я не нашел никакого упоминания о нем в статье. Вы его просто отключаете?
Хранить CSRF токен в куках плохо по той причине, что куки можно украсть, в чём собственно и состоит суть CSRF атаки.
Поправьте меня если я ошибаюсь, но суть CSRF не в воровстве куков. Если мы можем украсть куки, то нам не страшны никакие CSRF токены, потому что мы просто будем использовать куки, а токен нам пришлет сервер.
Насколько я помню, проблема была в том, что аккаунт был зарегистрирован из России, а AWS крутилась где-то снаружи. В результате ВК периодически решал что неплохо бы проверить кто это пишет сообщения, и прямо посреди работы бота мог заблочить последующую отправку до тех пор пока я не заходил на инстанс AWS и руками не подтверждал что это действительно "я". Не помню точно, почему не перенес в Россию, вполне возможно что у амазона был жирный кредит, а тратиться на сервера не хотелось
В свое время был написан бот который пересылал в группу письма из почты. Крутился на AWS, но спустя некоторе время vk начал блокировать авторизацию, подсовывая капчу, в связи с чем бот был заброшен. А потом и телеграм подоспел с более адекватным API
Дело не в том как это разработано (объективно — написать трекер не самая сложная задача) и не про динамику роста (растете — хорошо, не растете — плохо). Если это промо, то должны быть фичи, исходя из которых я буду или не буду пользоваться вашим приложением. Желательно фичи которых нет у других или же сделаны у других плохо. Зайдя на toggl я вижу на странице features что есть отчеты и что он интегрируется с чем только можно. Вот это было бы полезно — чем вы лучше других и зачем сделали свой трекер.
Не похоже на статью. Я понимаю что это я пиарюсь, но можно же было описать чем вы лучше других трекеров (toggl, трекеры от фрилансерских сайтов, и т.д.). Сейчас весь пост можно уместить в ссылку на апстор и на лендинг.
Делал подобное около 3 лет назад, но на js. Суть была в том, что мы используем реализованную функцию проверки на столкновение, но запускаем ее на несколько тиков впереди. Соотвественно, если мы сталкиваемся через N тиков — прыгаем сейчас. Github
if len(str) != '': вернет True для любых str. Кроме того, str — встроенный тип, использовать его как имя не стоит. Также внутри функции norm_mob определяется переменная с таким же названием(norm_mob), что, на мой взгляд, не очень красивое решение. Отметил бы еще, что смешивать underscore_case и camelCase тоже не самый лучший подход.
Нет. XSS делать никогда не стоит.
safeне предназначен для рендеринга json. Со стороны django было большой глупостью назватьsafeфильтр, который делает крайне опасные вещи.Кстати, как вы контролируете, что получаете post от доверенного источника?
Фильтр
safeдействительно отключает экранирование, но использовать его в таких целях не стоит, потому что это верный путь к xss:?a=</script><script>alert(1)</script>Также совершенно непонятно как будет работать
'post_data': request.body, потому чтоrequest.bodyэтоbytes, соответственно рендерится он будет какpost: b''.Также django по-умолчанию требует csrf токен для non-safe методов, к которым в том числе относится post, однако я не нашел никакого упоминания о нем в статье. Вы его просто отключаете?
Ок, принято.
Я говорил не про важность использования CSRF в целом, а про конкретную цитату
Для эксплуатации CSRF нет необходимости красть куки.
То есть атаку на GET? Если GET не меняет состояние, то CSRF для него не нужен.
Но как? У нас есть кука, которую достали трояном. Мы с этой кукой идем на сайт и все, никакой CSRF токен нам больше не нужен.
Поправьте меня если я ошибаюсь, но суть CSRF не в воровстве куков. Если мы можем украсть куки, то нам не страшны никакие CSRF токены, потому что мы просто будем использовать куки, а токен нам пришлет сервер.
Насколько я помню, проблема была в том, что аккаунт был зарегистрирован из России, а AWS крутилась где-то снаружи. В результате ВК периодически решал что неплохо бы проверить кто это пишет сообщения, и прямо посреди работы бота мог заблочить последующую отправку до тех пор пока я не заходил на инстанс AWS и руками не подтверждал что это действительно "я". Не помню точно, почему не перенес в Россию, вполне возможно что у амазона был жирный кредит, а тратиться на сервера не хотелось
В свое время был написан бот который пересылал в группу письма из почты. Крутился на AWS, но спустя некоторе время vk начал блокировать авторизацию, подсовывая капчу, в связи с чем бот был заброшен. А потом и телеграм подоспел с более адекватным API
Дело не в том как это разработано (объективно — написать трекер не самая сложная задача) и не про динамику роста (растете — хорошо, не растете — плохо). Если это промо, то должны быть фичи, исходя из которых я буду или не буду пользоваться вашим приложением. Желательно фичи которых нет у других или же сделаны у других плохо. Зайдя на toggl я вижу на странице features что есть отчеты и что он интегрируется с чем только можно. Вот это было бы полезно — чем вы лучше других и зачем сделали свой трекер.
Не похоже на статью. Я понимаю что это я пиарюсь, но можно же было описать чем вы лучше других трекеров (toggl, трекеры от фрилансерских сайтов, и т.д.). Сейчас весь пост можно уместить в ссылку на апстор и на лендинг.
А в чем проблема именно класса Sum? В java можно в любой класс засунуть метод main и выполнить его.
Строго говоря, туда можно записать null
Делал подобное около 3 лет назад, но на js. Суть была в том, что мы используем реализованную функцию проверки на столкновение, но запускаем ее на несколько тиков впереди. Соотвественно, если мы сталкиваемся через N тиков — прыгаем сейчас. Github