Обнаружена критическая уязвимость в Ruby on Rails

у меня не запустилось

всё работает на 1.9

Ок, уязвимость есть, но, как я уже сказал, конвертируя данные в символы нужно отдавать себе отчет. Наверняка шло как фича и кто-то теперь будет недоволен. По поводу десериализации из yaml, надо бы проверить масштаб катастрофы. Конечно впихивать фрагменты yaml в xml.. это надо догадаться..

А вот нафига сюда arel приплели, мне не понятно.

конвертируя данные в символы нужно отдавать себе отчет.

Ага, скажи об этом девелоперам рейлса. Они как раз до этого момента не совсем осознавали.

хмл - специфичный формат, со страницы проще использовать application/x-www-form-urlencoded или json, потому может и не зря, но, в любом случае, стало безопаснее.

В треде уже несколько раз писали - уязвимость доступна независимо от того, используется ли формат XML в приложении, или не используется. Обработчик XML включен по умолчанию, запрос к веб-приложению злоумышленник может сочинить в любом формате, какой ему в голову взбредет.

Писал довольно объёмные веб приложения. Особой потребности не возникало никогда.

Любой список с парой-тройкой уровней вложенности для редактирования без использования своего велосипеда, разделяющего данные и представление, превратит пхпшный код в кашу. Ты либо велосипедил делая свою систему, либо просто врёшь.

Кроме того иногда проще сделать своё чем разбираться с написанным другими.

Только иногда. Использовать чужое готовое всегда и проще и дешевле, если оно работает как надо.

Только иногда. Использовать чужое готовое всегда и проще и дешевле, если оно работает как надо.

Было бы проще и дешевле если бы рельсоподобные говнокодеры не заполонили всё вокруг.

Нехрен оставлять форматы, которые не используются, зачем.

Кого ты называешь рельсоподобными говнокодерами?

Кромя пиромиды и жанги есть еще много чего. Да и доки у пирамиды норм, так что не надо тут

upd. Расскажи как ты быстро напишешь веб _приложение_ на чистом пхп, не используя фреймворки(1)
Ссылочку на непонятные функции по свежее пжлста(2)
Ссудя по твоим темам на форуме ты неосилил, ни жангу, ни пирамиду. Печально.

Решето. Поэтому я выбираю django.

конвертируя данные в символы нужно отдавать себе отчет

Этого не произойдет, потому что этого не произойдет никогда. Программисты ведь не дураки и такой порнографией заниматься не станут. Мы делаем наш продукт из расчета на нормальных разработчиков, которые не допускают ошибок при написании программ. Конечно наш язык не может похвастаться таким уровнем проверок как, скажем, с++, но если продуктом занимаются достаточно грамотные разработчики с использованием юнит-тестирования, то проблем не возникнет.

И еще тысячи оправданий. Поэтому все нормальные люди и обходят рубикостыли (как и все динамические костыли тащемта, за исключением случаев крайней необходимости) за тредевятьземель.

Охотно тебе поверю, но только с пруфом.

Ссылку на репозиторий rails в github на участок кода который с твоих слов написан «школьниками» с пояснением что там не так, иначе peace-door-ball

Не ты выбираеш django, это django выбирает тебя.

Куда ещё податься? Java которая жрёт гигабайты памяти, при этом объём писанины на ней почти такой же как если писать на C++ если не больше. И при этом она способна загнуть мощнейшие сервера на задачах на которые хватит i386 с 1 Mb памяти. Нет, Java и всё что с ней связано отпадает.

Scala(play, Lift) clojure(ring, Compojure) вообще их дофига, жрет память да, но это нормально. Или вы хотите сказать что аппликуха на пыхе будет работать такэе быстро как апликуха на JVM?

А где proof, что Django не решето? Не бывает софта в котором нет критических уязвимостей. Есть софт, в котором эти уязвимости не нашли, или что еще хуже нашли, но используют в черных целях, не открывая их общественности раньше времени.

Кроме того, Django уже давно потеряла весь раж, и в методике разработки приближается к PHP, с той лишь разницей, что код на Python, как правило более качествен, чем на PHP. Но вот цена поддержки, и гибкость системы в разы хуже.

Не бывает софта в котором нет критических уязвимостей.

А вот это неверно.

Ну если ты считаешь «Hello, world», который написан на чистом ASM (для уменьшения вероятности ошибки от компилятора) - то твое высказывание верно. Другой вопрос - а является ли простая программа «Hello, world» софтом? Потому что под софтом я подразумеваю программу, которая способна приносить практическую пользу, а не быть абсурдным примером, для опровержения вполне реальных и проверенных временем фактов.

Нехрен оставлять форматы, которые не используются, зачем.

В твоих проектах этот обработчик отключен?

один из немногих разумных комментариев

замолчи, ты глуп

У джанго есть фатальный недостаток - питон.

Ну а вообще, я заметил, что js кода всегда больше чем руби (в разы), я думаю, что пора переходить на более легкие платформы, чем раилс, и в первую очередь это goliath. Просто большая часть приложения призвана генерировать html текст, а я уже не вижу этом смысла.

https://github.com/rails/rails/commit/e80546cdec56a9c3fcaf6217cba08a02d789d2bc Сабж

нет, я вырубил конвертацию в символы (всмысле теперь) :)

Python замечательный язык. У многих рубистов и питонистов болезнь - ругать не попробовав. Именно такая взаимная болезнь.

Почему именно Goliath? В таком контексте может уже лучше Erlang взять? Все таки EventMachine при всей красоте Ruby, все таки те же грабли, что и Node.js. А так на Erlang можно будет еще развить инфраструктуру, или на крайний случай на Elixir.

и про Django я бы сказал наоборот.

У Python есть фатальный недостаток - Django. Именно в таком порядке и контексте, а не наоборот.

А как тебе Sinatra?

На сколько я знаю, то Goliath - это ответ на Node.js и использует механизм волокон (fibers) ... Сам что-нибудь делал на нем? Он правда так хорош? :)

Erlang.. Elixir

Я не понимаю значение термина «функциональное программирование», я не могу понять в чем кардинальные отличия. У меня возникает ощущение, что это какой-то маркетинг.

Может быть, если ты хорошо это понимаешь, объяснишь мне в двух словах.. это и еще в чем преимущества.

те же грабли, что и Node.js

А в чем, собственно грабли при механизме фибер+реактор?

У многих рубистов и питонистов болезнь - ругать не попробовав

Да нет, серьезно. Руби гораздо лучше позволяет создавать программные интерфейсы, например http://datamapper.org/getting-started.html против http://stackoverflow.com/questions/53428/what-are-some-good-python-orm-solutions Ну видно же, что гибкости синтаксиса не хватает.

Что мне нравится в руби: все объект (одинаковые правила для классов и объектов), обращение к объектам только через методы, пространство имен и модули. И ничего этого в питоне нет))

А как тебе Sinatra?

нормально)

Сам что-нибудь делал на нем?

На самом деле, мне нравится cramp, и кое что я на нем уже написал, но он больше не поддерживается, поэтому я хочу перейти на goliath, они похожи.

Он правда так хорош?

В теории, позволяет создавать самые производительные и интересные приложения. Асинхронность + полный контроль над запросом/ответом + мощь руби.

Goliath - это ответ на Node.js

Скорее EM и Node.js, можно как-то сравнивать.

В двух словах смысл функционального программирования не объясню, сам фанатом не являюсь. Мне собственно сам Erlang нравится, его подходы, а не фанатизм вокруг парадигмы. Мне нравится и его минимализм, его простота, в тоже время он динамически типизирован, но типизирован строго, есть OTP, нравится идея потоков с ящиком сообщений, которое выглядит линейным и последовательным кодом, по сравнению с callback-адом Node.JS, EM и Twisted, и всего подобного. Мне очень нравится такой простой, но очень действенный функциональный механизм как pattern-matching. Мне очень нравится подход «пусть оно упадет как можно раньше», и избавление от защитного программирования. И еще меня интересуют в Erlang утилиты статического анализа типов и кода, типа Wrangler, и Dyalizer. Руки пока не доходят до него, так чтобы хорошо покопаться, но мне нравятся эти вещи в нем. Это такой очень практичный инструмент, который не отвязан от реальности, как Haskell к примеру, или еще что-нибудь эдакое православное.

В сторону граблей я лишь имел ввиду callback модель EventMachine, и кто-то вроде жаловался. Но мне как-то пока случая не представилось с чистой EM, и c Goliath работать. Так что мне больше интересно, как оно в деле. Мне как раз интересно услышать мнение, опыт работы с этим инструментом. Может быть я просто «услышал звон», но не понял откуда он идет.

По поводу Python vs Ruby, могу сказать лишь то, что писал/пишу на обоих, обоими доволен. Просто философии разные, сильно разные .

Собственно на Python есть и обращение к объектам только через методы (если ты следуешь этому правилу, и за парой исключений). Но это не из философии Python. Пространства имен и модули в Python более чем есть, и гораздо более развиты, чем в Ruby. На StackOverflow, кто-то из Ruby Core Team вроде интересовался механизмом пакетов и модулей в Python, для заимствования идей в Ruby 2.0.

На Python есть хорошие и интересные ORM, и весьма удобные. Просто если смотреть с большим акцентом Ruby в голове, то да, они выглядят страшно. Но если смотреть, как бы так сказать, с принятием философии Python - то они очень даже ничего.

Пространства имен и модули в Python более чем есть, и гораздо более развиты, чем в Ruby.

Ну не правда же это, чувак. http://docs.python.org/2/tutorial/modules.html

import fibo
fib = fibo.fib # это с т.з. руби некрасиво

callback модель

Потому-то в Goliath обрабатывается последовательность фиберов. Интересно сколько общего между фиберами в руби и потоками в ерланге.. Думаю нужен какой-то пример, чтобы разобраться, предлагаю написать демоприложение со схожим функционалом.

А где импорт в классы/объекты, другие модули - где импорт в пространство имен?

from fibo import fib

еще раз

импорт в классы/объекты, другие модули

class MyClass:
  from fibo import fib

MyClass().fib(100)

Вот так вот можно сделать?

В руби один require может полностью изменить функционал приложения, нет же такого в питоне.

Ну вот ты только что сказал ключевое слово: с точки зрения Ruby. В этом и смысл, с точки зрения Python, в Ruby куча магии. О чем я и говорил - философии очень разные, поэтому ИМХО остается ИМХО, и делом вкуса. Тут не скажешь, что одно однозначно лучше другого.

По поводу разницы, думаю все таки разница есть. Если fibers в Ruby реализованы при помощи setjmp, то в Erlang думаю все сложнее. Потоки у них легковесны, у каждого своя куча маленькая, каждый имеет свой ящик сообщений, и плюс ко всему у Erlang свой собственный scheduler. Больших подробностей увы не знаю, но смею предположить, что реализации вообще не имеют ничего общего.

Идея в принципе хорошая сделать что-то со схожим функционалом. С другой стороны, можно взять что-то уже готовое и посмотреть (= Если Goliath на Fibers, можно посмотреть на Cowboy.

Вот так вот можно сделать?

если что, скажи, я разрешил

Вот кстати, можно попробовать ping pong сделать. В частности интересный перевод статьи от создателя Erlang Joe Armstrong: http://habrahabr.ru/post/31546/ в конце которой пример программы ping pong. Вполне можно попробовать такое на Fiber реализовать. Если таковой пример будет показателен.

поэтому ИМХО остается ИМХО, и делом вкуса

Ок, комментарий бессмысленный, но речь именно об управлении структурой классов и объектов руби, точнее об удобстве этого управления. Как я уже сказал, один require, который просто содержит толпу модулей, может полностью изменить, или существенно расширить функционал приложения. Как следствие модульность приложения становится более развитой. Вот этого нет в питоне.

Тут не скажешь, что одно однозначно лучше другого.

Я уже сказал что важно мне.

Согласен. Cпорим о вкусах и личных предпочтениях. Думаю продолжать не стоит, ибо смысла нет.

Вот так вот можно сделать?

Можно с поправкой на self. Уймись уже. Давай в следующий раз ты прочитаешь нужную доку, а не первую попавшуюся, и не один первый абзац, а хотя бы 2-3, прежде чем начнёшь делиться своими откровениями о неймспейсах в питоне.

Хинт: http://docs.python.org/2/tutorial/classes.html

не дрейф, я сейчас ковыряю это палочкой, но мнение у меня такое: в питоне нет модулей. То что в питоне называется модулем - это лишь способ подгрузки кода из файла, анлогия для руби - более продвинутый require (если тебе от этого легче). Но это далеко не mixin.

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

Вот из-за этого я и не смог полюбить руби и рейлс. Оно красиво в теории, но когда читаешь чужой код, разобраться в этом хитросплетении модулей и миксинов гораздо сложнее чем в туполобом питоновском множественном наследовании.

Вот так вот можно сделать?

В питоне обычно делают так:

from othermodule import SomeMixin

class MyClass(SomeMixin):
   def my_method(self):
       pass

Но это далеко не mixin.

В питоне есть множественное наследование.

Ваша объектная модель это какой-то бред. Я не понимаю зачем вы пытаетесь это впарить, да еще и рубистам.

Во-первых да «с поправкой на селф»

то бишь не

# Fibonacci numbers module

def fib(n):    # write Fibonacci series up to n
    a, b = 0, 1
    while b < n:
        print b,
        a, b = b, a+b

def fib2(n): # return Fibonacci series up to n
    result = []
    a, b = 0, 1
    while b < n:
        result.append(b)
        a, b = b, a+b
    return result

а

# Fibonacci numbers module

def fib(self,n):    # write Fibonacci series up to n
    a, b = 0, 1
    while b < n:
        print b,
        a, b = b, a+b

def fib2(self,n): # return Fibonacci series up to n
    result = []
    a, b = 0, 1
    while b < n:
        result.append(b)
        a, b = b, a+b
    return result

Т.е. методы объектов должны иметь качественное отличие ввиде первого аргумента. Мне заняться больше нечем кроме как первым аргументом self ставить, кто это придумал вообще.

Объекты не обновляются после расширения класса, вы вкурсе, что даже в js, если я расширяю прототип, то все его потомки получают его свойства. Вы понимаете, что у вас объекты менее функциональны чем в js?

Аналога extend для класса так же нет, только наследование. А вообще есть нормальный способ расширить функционал класса, или его не существует? Просто

>>> class A:
...     def a(self):
...             print 'aaa'
... 
>>> class B:
...     def b(self):
...             print 'bbb'
... 
>>> a = A()
>>> a.a()
aaa
>>> b = B()
>>> b.b()
bbb
>>> class B(A):pass
... 
>>> ab = B()
>>> ab.a()
aaa
>>> ab.b()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: B instance has no attribute 'b'

Вот из-за этого я и не смог полюбить руби и рейлс.

Нет, это прекрасно. Это делает рельсы (и все остальное написанное на руби) невероятно расширяемым.

оберни в @staticmethod и self станет не нужен, раз уж сильно хочется странного, всё остальное ни о чём, в том же js за расширение прототипов надо бить больно

На какой версии Rails там Redmine работает сейчас?

Вот из-за этого я и не смог полюбить руби и рейлс.

Более того, не надо путать теплое с мягким, причем тут любишь-не любишь, ты не можешь контролировать кто-как пишет на том, на чем пишет. Вопрос можно или нельзя: ответ нельзя, невозможно, не предусмотрено. А в руби можно и активно используется (значит нужно). Ты же, можешь не использовать, если не хочешь. Никто не против.

gem 'rails', '3.2.11'