Статью по ссылке теперь прочитал наконец, понял, о чем вы. Согласен в том, что никакой ракетной науки в защите от csrf нет, в нормальных фреймворках это делается почти тривиально, и что веб-разработчики должны знать, как писать защищенный от csrf (и других атак) код.
Квалификация квалификацией, но с безопасностью такая штука — она работает, когда включена по умолчанию (экранирование в шаблонах, защита от csrf), и нужно предпринять какие-то действия (пометить контроллер как свободный от csrf-защиты, пометить строку как безопасную для вывода), чтоб ее отключить, когда на это есть причина.
— Запретить передачу данных из форм на отличный от текущего домен? А как же такие полезные применениях данной возможности, как «умные» межсайтовые переходы, не говоря уже о системах биллинга, и банальных формах «яндекс.поиск по сайту»?
Запретить передачу данных через POST к себе с чужого домена, именно, с возможностью включения обратно.
Яндек.поиск и умные межсайтовые переходы должны выполняться (и выполняются) методом GET, при чем они тут? Для биллинга правильно csrf явно отключать и использовать другие средства защиты (подписи запросов и тд).
— Выводить уведомления и требовать подтверждения при отправке любых данных на другой домен? Сдается мне, выстроится очередь из желающих либо перейти на браузеры без этой надоедливой ерунды, либо каким-то образом отключить это. Межсайтовые запросы происходят куда чаще, чем вы привыкли это замечать. В том числе и через POST. Один только google рассылает их пачками.
Если гугл рассылкает POST-запросы пачками, то можно и 403 возвращать на эти запросы, т.к. нефиг. Про остальное не понял, о какой такой надоедливой ерунде идет речь.
— Ну и, напоследок, что делать, если я захочу позволить пользователям отправлять на свой сервис данные через POST откуда угодно без лишних проблем? Переезжать на другую планету, где из-за того, что не умеющие плавать способны утонуть, еще не залили бетоном все реки?
Что делать? Подумать и перехотеть. Т.к. если не перехотите — создатите у себя CSRF-уязвимость, вот и все. Опасной она будет или нет — зависит от ситуации, но без защиты любой пользователь сможет при наличии неких скиллов выполнить эту отправку данных от имени любого другого пользователя (например, с помощью XSS на стороннем сайте), и вы этому никак помешать не сможете.
Короче, я не очень понял, о чем это вы написали, увидел наезд на «молодые языки», понты про «квалификацию кодеров» и поэтому огрызаюсь так, уж простите.
Угу, конфиг замечательный, будет отсекать людей, от которых http_referer не дошел по какой-то причине (кривая прокся, настройки браузера, фаервол и тд) и выдавать им 403. http_referer — заголовок по rfc2616 необязательный, полагаться на его наличие не здорово.
По GET на сайт человек может попасть извне, с другого сайта (по ссылке). При этом csrf-токен в ссылку добавить нельзя (другой сайт этот токен никак не получит, тем более что токен может обновляться на каждый запрос). Поэтому при GET-запросах возможности защититься от CSRF нет => GET-запросы не должны выполнять действия, менеяющие данные, они должны просто отдавать информацию. Если этому правилу следовать, то CSRF-атаки через GET-запросы (== человек просто переходит по ссылке) будут безобидными.
POST же человек в большинстве случаев (не учитывая api и тд, где обычно предусматриваются другие средства защиты) выполняет с того же сайта. Перед этим запрашивается страница через GET и у сервера есть возможность передать csrf-токен в куке, который потом при POST-запросе можно проверить.
Браузеры работают так, что js с чужого домена прочесть не свою куку не может, поэтому правильный POST-запрос сгенерировать на js не получится. С помощью html формы — тем более (токену с чужого сервера там взяться неоткуда).
Они не отключали csrf, просто для защиты кроме включения защиты необходимо еще не делать глупостей и уважать http (не менять данные по GET-запросам, а использовать POST для этого).
Нифига не нормально, расширение какое-нибудь может ссылки префетчить, например. Выполнение действий по GET — это явный косяк. Правильно тут при нажатии на ссылку слать ajax POST-запрос, а для людей без аякса предусмотреть страничку с формой подтверждения.
Полуофициальный форк с поддержкой 3го питона ( bitbucket.org/vinay.sajip/django ) давно есть, он регулярно мерджится с апстримом и его скоро влить должны в транк. Лучше не пинать, а помогать — ставьте его, пробуйте, исправляйте, что не работает. Кого пинать-то? Над джангой точно такие же люди работают, по своей инициативе, никто им за это ничего не платит, за что их пинать-то.
Поддержку 3го питона мы в pytils на www.ekbpy.ru/ добавили ( github.com/kmike/pytils ), но там потом репозитории немного разошлись, смерджить руки ни у кого не дошли. Форк должен работать под питонами с 2.6 по 3.2.
По поводу % — никто его не уберет, там теперь пишут «the % operator is supplemented by a more powerful string formatting method, format()» — в версии 3.0 думали, что в 3.1 объявят устаревшим, но вроде передумали.
По поводу print. Минусы понятны — в простом случае писать на 2 скобки больше. Но в консоли с ipython его можно по-старому вызывать (т.к. ipython поддерживает вызов функций без скобок). Ну и в print теперь можно аргументы передавать и разыменовывать их print(*args), или саму print как коллбэк передавать куда-то в аргументы, так что и плюсы есть)
Можно еще вернуться к изначальному примеру от egorinsk (утилита на 5-6 функций). Если все эти 5-6 функций заменить на статические методы, то это не даст ровным счетом ничего, даже если они вызывают друг друга как-то, т.к. в статических методах класс будет точно так же зашит, как и неймспейс. В C++ (и вроде в Java) статические методы работают как staticmethod в питоне (это если рассуждать, какое значение термина «статический метод» более употребимо).
Ага, с этой проблемой сталкивался в django-fab-deploy: есть набор команд, которые как-то взаимодействуют, и если делать их отдельными функциями, а не методами одного класса, то переопределить отдельный шаг проблематично становится. Там если на функциях все оставлять, то нужно наборы коллбэков всюду передавать, классы тут более удобный синтаксис предоставляют. Ситуацию усугубляло то, что в fabric «задачи на классах» реализованы как «одна задача — один класс», а не «метод класса — задача», так что основанные на классах задачи fabric тут ровным счетом ничего не давали (в итоге пришлось делать чудной хак — у класса есть метод, который добавляет методы-задачи класса (помеченные декоратором) в модуль как отдельные функции — т.к. fabric умеет задач-функции и задачи-классы, но не умеет задачи-методы классов).
Про статические методы — немного схитрил, т.к. в питоне есть staticmethod, который внутри вызывать другие статические методы может только явно указывая текущий класс — опять привязываясь к конкретной реализации. classmethod имеет больше смысла, а то и нормальный метод.
Другое дело, что часто даже для несвязанных друг с другом функций классы используются в качестве неймспейсов, для таксономии, организации кода. Вот в этом смысла вроде нет (я по крайней мере, придумать его не могу — может знаешь?), и вот тут питоньи неймспейсы делают то же самое, только проще. Т.е. классы, как мне кажется, лучше использовать, когда они дают какие-то конкретные преимущества, а не «по умолчанию» просто для организации кода.
Функции как раз тестировать проще, чем методы: не нужно конструировать полное состояние объекта и проверять работу в различных состояниях; все, от чего зависит результат, явно перечислено в параметрах. По этой же причине функции легче повторно использовать, чем методы. И по этой же причине код с функциями может тяготеть к меньшей связности — когда пишешь функцию, то явно задумываешься о том, какие ей нужны данные, есть больше стимулов написать ее так, чтоб она выполняла одно строго определенное действие. Состояние у объектов класса — это такие «глобальные переменные» в миниатюре.
Если же есть объект с методами и состоянием, легко завязать его методы на состояние, легче появляются неявные связи и зависимости между методами, сложнее понимать, как что работает (т.к. чтоб понять, как работает метод, недостаточно посмотреть в этот метод, нужно еще понимать, откуда берется состояние — а оно, возможно, суперклассом вычисляется или еще где-то, даже в сам класс посмотреть недостаточно бывает, чтоб понять, как работает какая-то его часть).
Про стабать и мокать — в питоне это совершенно без разницы, что функцию, что метод мокать. К тому же с функциями стабать и мокать нужно при тестах реже, т.к. связность кода меньше.
У классов есть преимущества — например, более удобный синтаксис для переопределения какой-то одной части вычислений при сложном взаимодействии (через наследование), или более удобный/привычный синтаксис, когда состояние все-таки есть, оно неизбежно и с ним нужно работать как-то. Короче, баланс какой-то искать всегда лучше — но плюсов у функций много.
В питоне нормальные неймспейсы и система импортов, статические методы классов поэтому там редко когда нужны.
C восторгом про ООП обычно отзываются те, кто его не так давно познал (=2-4 года с ООП, из них год-другой с паттернами), и при этом всякие SCIP не читал. Есть, конечно, другая крайность — люди, которые пописали с классами-паттренами что-то java-подобное лет 5-10, потом только вот прочитали SCIP и «прозрели», тут все вообще на функциях переписывать начинают, с map/reduce/curry/рекурсией где нужно и где ненужно. Возможно, потом этап «по дефолту — функции, если где-то это жмет — класс» наступает. Но я лично без понятия, как правильней и лучше всего) imho оно и есть imho
Запретить передачу данных через POST к себе с чужого домена, именно, с возможностью включения обратно.
Яндек.поиск и умные межсайтовые переходы должны выполняться (и выполняются) методом GET, при чем они тут? Для биллинга правильно csrf явно отключать и использовать другие средства защиты (подписи запросов и тд).
Если гугл рассылкает POST-запросы пачками, то можно и 403 возвращать на эти запросы, т.к. нефиг. Про остальное не понял, о какой такой надоедливой ерунде идет речь.
Что делать? Подумать и перехотеть. Т.к. если не перехотите — создатите у себя CSRF-уязвимость, вот и все. Опасной она будет или нет — зависит от ситуации, но без защиты любой пользователь сможет при наличии неких скиллов выполнить эту отправку данных от имени любого другого пользователя (например, с помощью XSS на стороннем сайте), и вы этому никак помешать не сможете.
Короче, я не очень понял, о чем это вы написали, увидел наезд на «молодые языки», понты про «квалификацию кодеров» и поэтому огрызаюсь так, уж простите.
POST же человек в большинстве случаев (не учитывая api и тд, где обычно предусматриваются другие средства защиты) выполняет с того же сайта. Перед этим запрашивается страница через GET и у сервера есть возможность передать csrf-токен в куке, который потом при POST-запросе можно проверить.
Браузеры работают так, что js с чужого домена прочесть не свою куку не может, поэтому правильный POST-запрос сгенерировать на js не получится. С помощью html формы — тем более (токену с чужого сервера там взяться неоткуда).
По поводу print. Минусы понятны — в простом случае писать на 2 скобки больше. Но в консоли с ipython его можно по-старому вызывать (т.к. ipython поддерживает вызов функций без скобок). Ну и в print теперь можно аргументы передавать и разыменовывать их print(*args), или саму print как коллбэк передавать куда-то в аргументы, так что и плюсы есть)
а в 3ке можно просто
Про статические методы — немного схитрил, т.к. в питоне есть staticmethod, который внутри вызывать другие статические методы может только явно указывая текущий класс — опять привязываясь к конкретной реализации. classmethod имеет больше смысла, а то и нормальный метод.
Другое дело, что часто даже для несвязанных друг с другом функций классы используются в качестве неймспейсов, для таксономии, организации кода. Вот в этом смысла вроде нет (я по крайней мере, придумать его не могу — может знаешь?), и вот тут питоньи неймспейсы делают то же самое, только проще. Т.е. классы, как мне кажется, лучше использовать, когда они дают какие-то конкретные преимущества, а не «по умолчанию» просто для организации кода.
Если же есть объект с методами и состоянием, легко завязать его методы на состояние, легче появляются неявные связи и зависимости между методами, сложнее понимать, как что работает (т.к. чтоб понять, как работает метод, недостаточно посмотреть в этот метод, нужно еще понимать, откуда берется состояние — а оно, возможно, суперклассом вычисляется или еще где-то, даже в сам класс посмотреть недостаточно бывает, чтоб понять, как работает какая-то его часть).
Про стабать и мокать — в питоне это совершенно без разницы, что функцию, что метод мокать. К тому же с функциями стабать и мокать нужно при тестах реже, т.к. связность кода меньше.
У классов есть преимущества — например, более удобный синтаксис для переопределения какой-то одной части вычислений при сложном взаимодействии (через наследование), или более удобный/привычный синтаксис, когда состояние все-таки есть, оно неизбежно и с ним нужно работать как-то. Короче, баланс какой-то искать всегда лучше — но плюсов у функций много.
C восторгом про ООП обычно отзываются те, кто его не так давно познал (=2-4 года с ООП, из них год-другой с паттернами), и при этом всякие SCIP не читал. Есть, конечно, другая крайность — люди, которые пописали с классами-паттренами что-то java-подобное лет 5-10, потом только вот прочитали SCIP и «прозрели», тут все вообще на функциях переписывать начинают, с map/reduce/curry/рекурсией где нужно и где ненужно. Возможно, потом этап «по дефолту — функции, если где-то это жмет — класс» наступает. Но я лично без понятия, как правильней и лучше всего) imho оно и есть imho