Github hackeado por falla de vulnerabilidad en Rails
Bruno Deferrari
http://news.ycombinator.com/item?id=3663197
http://homakov.blogspot.com/2012/03/egor-stop-hacking-gh.html
"""
I'm not done yet. Why I do this? Since guys in rails issues ingored me
and my issue I got spare time to test it on the first website i had in
mind. github.
That was pretty funny. Firstly, I could write post from 1234 year or 4321.
Then, I could make a post pretending i am DHH. That was funny too.
Then I could wipe any post in any project. That wasn't that funny but
pretty dangereous. It got more curious.
Today I can pull/commit/push in any repository on github. Jack pot.
"""
--
BD
Bruno Deferrari
Nicolás Ayala
Bruno Deferrari
> Un ruso malo malo, de pelicula parece.
>
Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
en un post explicando.
Esto es una deficiencia de como están diseñados la mayoría de los
stacks en Ruby, que acoplan la validación del input de usuario en los
modelos. En aplicaciones en las que trabajo yo esto no se puede dar
porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
nivel de modelo siquiera.
Por cierto, esto de tener handlers para formularios en ves de manejar
eso a nivel de los modelos no es nada loco, es como se vienen haciendo
las cosas en Python desde hace mucho (Bureaucrat no es más que una
versión para Ruby de lo que provee Django). Para mi es el approach
superior, no solo simplifica el resultado al dividir las
responsabilidades a quien le corresponde, también es más seguro.
--
BD
Michel Martens
> Por cierto, esto de tener handlers para formularios en ves de manejar
> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
> las cosas en Python desde hace mucho (Bureaucrat no es más que una
> versión para Ruby de lo que provee Django). Para mi es el approach
> superior, no solo simplifica el resultado al dividir las
> responsabilidades a quien le corresponde, también es más seguro.
+1
Estamos usando Bureaucrat para algunos proyectos y Scrivener para
otros, y es algo que quería comentar en el Ruby Argentina meetup de
Febrero. Estamos organizando el meetup de Marzo y si tenemos tiempo
podría mencionarlo ahí.
Bureaucrat: https://github.com/tizoc/bureaucrat
Scrivener: https://github.com/soveran/scrivener
Guillermo Iguaran
http://guides.rubyonrails.org/security.html
Mas para leer:
http://jonathanleighton.com/articles/2011/mass-assignment-security-shouldnt-happen-in-the-model/
Al igual que Bruno y Michel me gusta la idea de usar Bureaucrat
Perdon por el top posting y la falta de acentos.
Sent from my iPhone
Nicolas Sanguinetti
> 2012/3/4 Nicolás Ayala <ncls....@gmail.com>:
>> Un ruso malo malo, de pelicula parece.
>>
>
> Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
> en un post explicando.
>
> Esto es una deficiencia de como están diseñados la mayoría de los
> stacks en Ruby, que acoplan la validación del input de usuario en los
> modelos. En aplicaciones en las que trabajo yo esto no se puede dar
> porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
> nivel de modelo siquiera.
>
> Por cierto, esto de tener handlers para formularios en ves de manejar
> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
> las cosas en Python desde hace mucho (Bureaucrat no es más que una
> versión para Ruby de lo que provee Django). Para mi es el approach
> superior, no solo simplifica el resultado al dividir las
> responsabilidades a quien le corresponde, también es más
El tema es que es un problema social. Desde hace años que podes poner en un initializer:
class ActiveRecord::Base
attr_accessible nil
end
Y eso fuerza a todos los modelos a ser protected por omisión.
No digo que sea un mejor approach el de hacer esto en los modelos--todo lo contrario. Pero la seguridad es un tema de responsabilidad del developer. El framework puede ayudar, pero al final del día tenes que entender como/por que pasan las cosas y como las haces seguras, uses rails, django, o alguna cosa rara en php.
-foca
Bruno Deferrari
> On 04/03/2012, at 16:07, Bruno Deferrari <uti...@gmail.com> wrote:
>
>> 2012/3/4 Nicolás Ayala <ncls....@gmail.com>:
>>> Un ruso malo malo, de pelicula parece.
>>>
>>
>> Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
>> en un post explicando.
>>
>> Esto es una deficiencia de como están diseñados la mayoría de los
>> stacks en Ruby, que acoplan la validación del input de usuario en los
>> modelos. En aplicaciones en las que trabajo yo esto no se puede dar
>> porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
>> nivel de modelo siquiera.
>>
>> Por cierto, esto de tener handlers para formularios en ves de manejar
>> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
>> las cosas en Python desde hace mucho (Bureaucrat no es más que una
>> versión para Ruby de lo que provee Django). Para mi es el approach
>> superior, no solo simplifica el resultado al dividir las
>> responsabilidades a quien le corresponde, también es más
>
> El tema es que es un problema social. Desde hace años que podes poner en un initializer:
>
> class ActiveRecord::Base
> attr_accessible nil
> end
>
> Y eso fuerza a todos los modelos a ser protected por omisión.
>
> No digo que sea un mejor approach el de hacer esto en los modelos--todo lo contrario. Pero la seguridad es un tema de responsabilidad del developer. El framework puede ayudar, pero al final del día tenes que entender como/por que pasan las cosas y como las haces seguras, uses rails, django, o alguna cosa rara en php.
>
Es una falla de diseño que tu aplicación por defecto sea insegura,
punto. Lo que vos me estás diciendo es equivalente a "bueno pero ese
agujero de seguridad X lo podés parchear, es tu responsabilidad".
Igual más allá de los problemas de seguridad, desde el punto de vista
de diseño, está mal que ese tipo de validaciones las haga el modelo,
es demasiada responsabilidad y asume que por cada modelo tenés un solo
form con una sola configuración, es estúpido.
Si yo te doy una librería para comunicarse con la base de datos cuya
solución para SQL es la interpolación de strings en ves de parámetros,
vas a negar que es insegura por diseño?
--
BD
Bruno Deferrari
> 2012/3/4 Nicolas Sanguinetti <god...@gmail.com>:
>> On 04/03/2012, at 16:07, Bruno Deferrari <uti...@gmail.com> wrote:
>>
>>> 2012/3/4 Nicolás Ayala <ncls....@gmail.com>:
>>>> Un ruso malo malo, de pelicula parece.
>>>>
>>>
>>> Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
>>> en un post explicando.
>>>
>>> Esto es una deficiencia de como están diseñados la mayoría de los
>>> stacks en Ruby, que acoplan la validación del input de usuario en los
>>> modelos. En aplicaciones en las que trabajo yo esto no se puede dar
>>> porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
>>> nivel de modelo siquiera.
>>>
>>> Por cierto, esto de tener handlers para formularios en ves de manejar
>>> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
>>> las cosas en Python desde hace mucho (Bureaucrat no es más que una
>>> versión para Ruby de lo que provee Django). Para mi es el approach
>>> superior, no solo simplifica el resultado al dividir las
>>> responsabilidades a quien le corresponde, también es más
>>
>> El tema es que es un problema social. Desde hace años que podes poner en un initializer:
>>
>> class ActiveRecord::Base
>> attr_accessible nil
>> end
>>
>> Y eso fuerza a todos los modelos a ser protected por omisión.
>>
Otra cosa, esto resulta en algo re incómodo, porque querés validar las
cosas solo para el input de usuario, hacer esto hace que cualquier
interacción con los modelos sea más incómoda, no?
Algo más que quiero resaltar es que estamos hablando de Github acá, no
de un sitio random cualquiera. Se supone que Github es el epítome del
desarrollo web en Rubylandia no? que su equipo está integrado por
gente de la más capaz que es en el entorno, y aún así, cayeron en
esto. Creo que si gente tan capaz tiene un problema de seguridad tan
choto, no habla tan bien de como está armada la herramienta.
--
BD
Michel Martens
>
> Algo más que quiero resaltar es que estamos hablando de Github acá, no
> de un sitio random cualquiera. Se supone que Github es el epítome del
> desarrollo web en Rubylandia no? que su equipo está integrado por
> gente de la más capaz que es en el entorno, y aún así, cayeron en
> esto. Creo que si gente tan capaz tiene un problema de seguridad tan
> choto, no habla tan bien de como está armada la herramienta.
Está bueno este artículo que mandó @matiasow en un tweet:
http://chrisacky.posterous.com/github-you-have-let-us-all-down
Bruno Deferrari
https://github.com/rails/rails/issues/5228#issuecomment-4314205
'"Insecure-by-default" means "insecure". Trusting the programmer to
fix things up and make them secure has never worked.'
--
BD
Luis Lavena
Omg, another rails soap opera...
Dejen de joder, la respuesta de github fue una mentira y la manera en que el ruso se manejo estuvo mal.
Para eso existen las listas de security y hay ciertas reglas para el reporte de un exploit.
En lo que respecta a que le cerraron el issue los de rails, nada fuera de lo común: muchos de ellos se creen perfectos y poseedores de la verdad.
Irónico leer un post de Jason fried de como deberíamos darle 5 minutos a las cosas antes de reaccionar (en el blog de 37 signals)
Por todo lo demás: el que no leyó el fucking manual y aseguro sus modelos en su momento, creo ahora seria lo ideal.
Personalmente considero es una falla del framework.
Sorry for top posting. Sent from mobile.
Bruno Deferrari
> Omg, another rails soap opera...
>
> Dejen de joder, la respuesta de github fue una mentira y la manera en que el
> ruso se manejo estuvo mal.
>
Inmadura? si, efectiva? totalmente. Lamentablemente si no pasan estas
cosas nadie da bola.
--
BD
Nacho Facello
de los desarrolladores cuando siempre dijimos todos que lo de
register_globals en PHP era un problema de PHP y no de los
desarrolladores. Un poco de consistencia, ¿no?
2012/3/4 Bruno Deferrari <uti...@gmail.com>:
--
Nacho Facello
:wq
Bruno Deferrari
> Creo que no pueden venir a decirme que no es un problema de Rails sino
> de los desarrolladores cuando siempre dijimos todos que lo de
> register_globals en PHP era un problema de PHP y no de los
> desarrolladores. Un poco de consistencia, ¿no?
>
https://twitter.com/dhh/status/176465643107909632
Bueno, ahora que DHH lo dice, el punto de vista de que hacer eso en
los modelos apesta está totalmente validado no? Al final, es el que
hizo Rails, famoso y prestigioso.
Btw, en Python esto lo tienen resuelto desde hace al menos 6+ años
(probablemente más, desde que existe Django y su abstracción para
forms html, patrón del cual cual hay muchas variantes implementadas en
Pythonlandia).
--
BD
Nacho Facello
> 2012/3/4 Nacho Facello <na...@nucleartesuji.com>:
>> Creo que no pueden venir a decirme que no es un problema de Rails sino
>> de los desarrolladores cuando siempre dijimos todos que lo de
>> register_globals en PHP era un problema de PHP y no de los
>> desarrolladores. Un poco de consistencia, ¿no?
>>
>
> https://twitter.com/dhh/status/176465643107909632
>
> Bueno, ahora que DHH lo dice, el punto de vista de que hacer eso en
> los modelos apesta está totalmente validado no? Al final, es el que
> hizo Rails, famoso y prestigioso.
>
> Btw, en Python esto lo tienen resuelto desde hace al menos 6+ años
> (probablemente más, desde que existe Django y su abstracción para
> forms html, patrón del cual cual hay muchas variantes implementadas en
> Pythonlandia).
El problema no es la solución. Creo que está bastante claro de por
dónde tiene que venir (si bien la implementación exacta puede variar).
El problema está por el lado de cómo llevás a Rails desde Rails a
actual a un Rails con validaciones por form (o por actividad, que
capaz que querés validar al importar datos en un cron, por ejemplo;
pero no viene al caso). El tema es que querés a) mantener la mayor
compatibilidad posible y b) que no queden aplicaciones usando el
método inseguro.
--
Nacho Facello
:wq
Bruno Deferrari
Nacho, come on, lo estábamos discutiendo en la oficina el otro día
esto. Desde cuándo es tan importante la compatibilidad hacia atrás
para Rails? Cualquier proyecto que arranques en Rails hoy, se va a
quedar obsoleto muy rápido, y migrar a una versión más nueva no es
cómodo.
Además, agregando una abstracción extra no agregás ninguna
incompatibilidad, lo que es malo es que te queda de clavo el código
necesario para soportar un patrón que ya se sabe está fallado.
Lamentablemente ya me veo que la "solución" va a ser pedorra. Cambiar
el default no es una gran solución, y eso que vi por ahí que propone
Yehuda tampoco me parece muy bueno.
--
BD
Nacho Facello
Es un buen punto lo segundo, anula lo que te iba a responder a lo primero.
> Lamentablemente ya me veo que la "solución" va a ser pedorra. Cambiar
> el default no es una gran solución, y eso que vi por ahí que propone
> Yehuda tampoco me parece muy bueno.
No ví eso. ¿Link?
--
Nacho Facello
:wq
Bruno Deferrari
Nacho Facello
> http://news.ycombinator.com/item?id=3663341
Justo acababa de llegar a eso por reddit. No me gusta. Meter en la
vista eso suena a un poco chancho. No veo porqué no meterlo en el
controller.
>
> Y lo que hace DHH:
>
> https://twitter.com/dhh/status/176465426925109250
Eso tiene bastante más sentido.
>
>> --
>> Nacho Facello
>> :wq
>
>
>
> --
> BD
--
Nacho Facello
:wq
Bruno Deferrari
> 2012/3/4 Bruno Deferrari <uti...@gmail.com>:
>> http://news.ycombinator.com/item?id=3663341
>
> Justo acababa de llegar a eso por reddit. No me gusta. Meter en la
> vista eso suena a un poco chancho. No veo porqué no meterlo en el
> controller.
>
>>
>> Y lo que hace DHH:
>>
>> https://twitter.com/dhh/status/176465426925109250
>
> Eso tiene bastante más sentido.
>
Siempre y cuando tu aplicación sea un CRUD aburrido donde cada form
submission se mapea directamente a un save de un modelo, y donde todos
los fields del form mapeen directo a propiedades de tu modelo. No se
vos, pero las cosas que yo hago, a no ser que sean muy básicas, no son
así.
>>
>>> --
>>> Nacho Facello
>>> :wq
>>
>>
>>
>> --
>> BD
>
>
>
> --
> Nacho Facello
> :wq
--
BD
Ary Borenszweig
Nacho Facello
Bueno, sí, es cierto, pero ahí ya no apuntás al problema de seguridad en cuestión, sino que apuntás a un problema de diseño más de fondo. Y, como bien dijeron, en esos forms más complejos no estás usando update_attributes de todas formas.
Bruno Deferrari
> Bueno, sí, es cierto, pero ahí ya no apuntás al problema de seguridad en
> cuestión, sino que apuntás a un problema de diseño más de fondo. Y, como
> bien dijeron, en esos forms más complejos no estás usando update_attributes
> de todas formas.
>
Es un problema en cuanto a que filtrar las cosas así no es práctico,
las soluciones para casos re básicos no son soluciones en serio.
Y si, va más allá del tema seguridad, el tema de seguridad no es más
que un side-effect de tener un mal diseño.
--
BD
Bruno Deferrari
Bruno Deferrari
Explicación del ruso de lo que hizo (que es recontra básico, pero igual).
http://homakov.blogspot.com/2012/03/how-to.html
--
BD
Nicolás Sanguinetti
> Es una falla de diseño que tu aplicación por defecto sea insegura,
> punto. Lo que vos me estás diciendo es equivalente a "bueno pero ese
> agujero de seguridad X lo podés parchear, es tu responsabilidad".
> Igual más allá de los problemas de seguridad, desde el punto de vista
> de diseño, está mal que ese tipo de validaciones las haga el modelo,
> es demasiada responsabilidad y asume que por cada modelo tenés un solo
> form con una sola configuración, es estúpido.
No, yo no estoy defendiendo lo que hace rails, lo dije, me parece que
está mal. Lo que yo estoy diciendo es que más allá de lo que ofrezca
el framework o no, es tu trabajo entender de seguridad y asegurar tu
aplicación.
El tema del mass-assignment, en particular, es una garcha, y recién en
3.2 tenés una forma de hacer que sea todo protected por defecto
"prolija", pero desde hace años que podés "arreglarlo" vos de forma
que tu app no sea insegura.
No digo que sea lo mejor, digo que igual hay una cuota de falta de
conocimiento por los developers.
Si el framework hace todo por vos, bien, pero si no sabés lo que está
pasando atrás, entonces es tu problema tanto como el del framework.
Trabajamos en cosas que requieren conocimientos básicos de seguridad
(no te digo que tenés que ser un experto—yo no lo soy, ni cerca—pero
tenés que entender las básicas). Si no tenés esos conceptos, entonces
no hay framework ni librería que te salven.
Sí, es un problema de diseño de rails. Then again, está documentado, y
podés evitarlo. La culpa es tanto de rails por tener un mal diseño,
como de los developers que no toman medidas para que su aplicación sea
segura.
> Si yo te doy una librería para comunicarse con la base de datos cuya
> solución para SQL es la interpolación de strings en ves de parámetros,
> vas a negar que es insegura por diseño?
ActiveRecord escapa los queries que genera si le pasás los valores de
una forma que está bien documentada (y que te la explican en cualquier
manual/libro/guía sobre ARec). Sabés cuántas apps agarré hechas por
otra gente que interpolaban parámetros del request en el query así
nomás? Muchas :P
Que la librería/framework/whatever no haga las cosas por vos no es
excusa para que seas un ignorante y las hagas mal igual.
-f
Bruno Deferrari
Son cosas independientes. Mi punto es que "es responsabilidad de los
developers que usan el api" no es la respuesta correcta a "este diseño
apesta".
PHP register globals.
--
BD
Nicolás Sanguinetti
> PHP register globals.
Y magic quotes, bo, no se olviden de magic quotes.
Bruno Deferrari
Y vuelvo a repetir lo mismo, aplicaciones de gente que en teoría sabe
lo que hace tiene esta falla. No solo fue en Github, también en
Posterous.
--
BD
Nacho Facello
> Y magic quotes, bo, no se olviden de magic quotes.
Pah, magic_quotes era lo peor del mundo.
--
Nacho Facello
:wq
Instr. Dwayne Macgowan
Dwayne Macgowan Instructor del Método DeRose Para conocer el Método DeRose visitá: Blog de DeRose |
|
Damian Janowski
>
> Hicieron attr_accesible obligatorio ahora (para que funciona update_attributes)
> https://github.com/rails/rails/commit/641a4f62405cc2765424320932902ed8076b5d38
Hasta DHH se dio cuenta, y aún así siguen insistiendo con el modelo :)
Nicolás Sanguinetti
Seh, aunque ese commit es en 3-2-stable. Me parece bien que no rompan
todo entre 3.2.2 y 3.2.3, no? Esto es un parche "suficientemente
bueno" para un point release.
Dado que master ahora ya es 4.0, estaría bueno un cambio grande ahí.
Ni idea si lo van a hacer o no (ponele que deberían, pero ta, no en un
point release).
-f
Michel Martens
> Ni idea si lo van a hacer o no (ponele que deberían, pero ta, no en un
> point release).
Creo que lo trataría como un security fix.
Santiago Pastorino
> On 04/03/2012, at 16:07, Bruno Deferrari <uti...@gmail.com> wrote:
>
>> 2012/3/4 Nicolás Ayala <ncls....@gmail.com>:
>>> Un ruso malo malo, de pelicula parece.
>>>
>>
>> Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
>> en un post explicando.
>>
>> Esto es una deficiencia de como están diseñados la mayoría de los
>> stacks en Ruby, que acoplan la validación del input de usuario en los
>> modelos. En aplicaciones en las que trabajo yo esto no se puede dar
>> porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
>> nivel de modelo siquiera.
>>
>> Por cierto, esto de tener handlers para formularios en ves de manejar
>> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
>> las cosas en Python desde hace mucho (Bureaucrat no es más que una
>> versión para Ruby de lo que provee Django). Para mi es el approach
>> superior, no solo simplifica el resultado al dividir las
>> responsabilidades a quien le corresponde, también es más
>
> El tema es que es un problema social. Desde hace años que podes poner en un initializer:
>
> class ActiveRecord::Base
> attr_accessible nil
> end
No es necesario hacer eso, vos lo que queres es agregar esto ...
# Enforce whitelist mode for mass assignment.
# This will create an empty whitelist of attributes available for
mass-assignment for all models
# in your app. As such, your models will need to explicitly
whitelist or blacklist accessible
# parameters by using an attr_accessible or attr_protected declaration.
config.active_record.whitelist_attributes = true
al application.rb
Santiago Pastorino
> 2012/3/4 Bruno Deferrari <uti...@gmail.com>:
>> 2012/3/4 Nicolas Sanguinetti <god...@gmail.com>:
>>> On 04/03/2012, at 16:07, Bruno Deferrari <uti...@gmail.com> wrote:
>>>
>>>> 2012/3/4 Nicolás Ayala <ncls....@gmail.com>:
>>>>> Un ruso malo malo, de pelicula parece.
>>>>>
>>>>
>>>> Un ruso bueno, abrió un issue, dice que está trabajando en el fix, y
>>>> en un post explicando.
>>>>
>>>> Esto es una deficiencia de como están diseñados la mayoría de los
>>>> stacks en Ruby, que acoplan la validación del input de usuario en los
>>>> modelos. En aplicaciones en las que trabajo yo esto no se puede dar
>>>> porque todo pasa antes por Bureaucrat, de hecho no uso validaciones a
>>>> nivel de modelo siquiera.
>>>>
>>>> Por cierto, esto de tener handlers para formularios en ves de manejar
>>>> eso a nivel de los modelos no es nada loco, es como se vienen haciendo
>>>> las cosas en Python desde hace mucho (Bureaucrat no es más que una
>>>> versión para Ruby de lo que provee Django). Para mi es el approach
>>>> superior, no solo simplifica el resultado al dividir las
>>>> responsabilidades a quien le corresponde, también es más
>>>
>>> El tema es que es un problema social. Desde hace años que podes poner en un initializer:
>>>
>>> class ActiveRecord::Base
>>> attr_accessible nil
>>> end
>>>
>>>
>
> Otra cosa, esto resulta en algo re incómodo, porque querés validar las
> cosas solo para el input de usuario, hacer esto hace que cualquier
> interacción con los modelos sea más incómoda, no?
>
> Algo más que quiero resaltar es que estamos hablando de Github acá, no
> de un sitio random cualquiera. Se supone que Github es el epítome del
> desarrollo web en Rubylandia no? que su equipo está integrado por
> gente de la más capaz que es en el entorno, y aún así, cayeron en
> esto. Creo que si gente tan capaz tiene un problema de seguridad tan
> choto, no habla tan bien de como está armada la herramienta.
Si bien estoy de acuerdo contigo y Rails VA a ser más seguro por
defecto y va a sacar estos controles de ActiveRecord ...
Es un error de jardín de infantes.
Santiago Pastorino
Igual reitero, estoy de acuerdo que Rails tiene un punto de mejora
importante acá y debería ser seguro por defecto.
Pero hay mucha gente en la vuelta que le quiere responsabilizar a
Rails del agujero de seguridad de github, no me parece correcto.
Bruno Deferrari
Que afectó a Github y Posterous y imagino casi todos los sitios. Igual
a mi no me molesta tanto lo de seguridad, es algo de costado.
Vos qué pensás de lo que hace Django? (o WTForms, o
Colander+Peppercorn+Deform de Pylons, o cualquiera de las otras varias
opciones que hay en Python)
Yo cuando empecé a trabajar con Ruby esto fue lo que más me molestó, y
por eso me puse a portar lo que ofrece Django.
No estaría bueno que Rails tuviera algo así? con la existencia de
ActiveModel y las validaciones ya separadas creo que la mayoría del
laburo ya está hecho.
--
BD
Bruno Deferrari
No es responsabilidad de Rails, lo único que se puede decir al
respecto es que el diseño es malo. Ni siquiera es un bug.
--
BD
Santiago Pastorino
Bruno Deferrari
Y se puede saber cómo? Porque entre poner un filtro a nivel de
controlador y hacer lo que hace Django (y Python en general) hay un
trecho enorme.
Mi duda es si el Rails core ve todo el acoplamiento que hay en los
modelos como un problema o se sigue pensando que eso de "Fat Models"
es la posta.
--
BD
Santiago Pastorino
Sí, pero aún está en discusión ... tenés las primeras ideas en este
gist https://gist.github.com/1974187
> Mi duda es si el Rails core ve todo el acoplamiento que hay en los
> modelos como un problema o se sigue pensando que eso de "Fat Models"
> es la posta.
Está claro que no es la posta. De hecho una cosa que estoy de acuerdo
con uno de los artículos que hay en la vuelta es que TDD es
impracticable (casi) en Rails y hay que mejorar. Hay que mejorar el
boot time, entre otras cosas.
Te puedo asegurar que el Rails core es bastante crítico de los
problemas del framework, mucho más de lo que la gente se imagina y
esas críticas sirven para mejorarlo.
Saludos!
Bruno Deferrari
Lo que propone wycats es una cagada, pero veo que hay gente en los
comentarios que está proponiendo seguir el mismo patrón de Django,
espero que les den bola. Una parte muy buena de lo que hace Django es
que lograron compartir mucha de la lógica de validación entre los
Forms y los Modelos, al punto en que la integración que tienen te
permite que al validar algo en un Form, no tengas que revalidarlo en
el save del Modelo. También tienen los "ModelForms" que son Forms
construidos automáticamente a partir de la definición de un Modelo, lo
cual te ahorra tener que escribir toda la definición en el caso en que
tu Form mapea directo a un Modelo, supongo que para la gente de Rails
esto es un selling point porque aparentemente no les gusta escribir
mucho.
Estas 2 cosas (compartir validaciones, y crear un Form inspeccionando
el Modelo) son 2 cosas que Bureaucrat no resuelve justamente porque es
"model agnostic", pero que en Rails no sería un problema (ya sea a
nivel de ActiveRecord o ActiveModel).
Lamentablemente ya veo que wycats quiere meter su propuesta y no está
dando ni bola a los comentarios que proponen algo como lo de Django.
>> Mi duda es si el Rails core ve todo el acoplamiento que hay en los
>> modelos como un problema o se sigue pensando que eso de "Fat Models"
>> es la posta.
>
> Está claro que no es la posta. De hecho una cosa que estoy de acuerdo
> con uno de los artículos que hay en la vuelta es que TDD es
> impracticable (casi) en Rails y hay que mejorar. Hay que mejorar el
> boot time, entre otras cosas.
>
> Te puedo asegurar que el Rails core es bastante crítico de los
> problemas del framework, mucho más de lo que la gente se imagina y
> esas críticas sirven para mejorarlo.
>
> Saludos!
--
BD
Nicolás Sanguinetti
Sí, lo puse en otro mail más adelante que en 3.2 se puede hacer de
forma prolija. Pero 3.2 salió hace un par de meses, el problema de los
attr_accessible por defecto lo tenés desde hace 6 años.
:)
Michel Martens
> Sí, pero aún está en discusión ... tenés las primeras ideas en este
> gist https://gist.github.com/1974187
Estoy de acuerdo con Bruno y con quienes sugieren en los comentarios
que es mejor algo al estilo de lo que hace Django.
Me parece que se mezclan varios problemas:
1. Integridad de datos
Parecería ser responsabilidad del modelo (ya sea por medio de
validaciones o de constraints de la base de datos). El problema es que
es que las validaciones pueden depender del contexto: un campo cuyos
valores posibles son {1, 2, 3} puede tener la restricción de que sólo
puede ser creado con el valor 1. Puede haber otra restricción para que
el valor 3 sólo sea usado si otro campo cumple cierta condición. En un
escenario así, la integridad de datos va a depender de un montón de
ifs.
Entonces se puede pensar en una integridad de datos más de base: el
modelo valida que el valor esté en {1, 2, 3}, o directamente valida
que sea un entero, y las validaciones de nivel más alto las delega a
otra capa. Este tipo de validaciones pueden estar en el schema de la
base de datos.
2. Transformaciones
Cuando los datos provienen de un formulario, a veces hay que
adaptarlos para que se guarden con determinado formato. Esto me parece
que no le corresponde al modelo: si no recibe los datos en la forma en
que los necesita, debería estallar. Las transformaciones deberían
ocurrir en otra capa.
3. Interacciones / Restricciones
Esto es lo que motivó los cambios que están haciendo en Rails. El
problema que le veo a attr_accessible es que no tiene en cuenta los
distintos contextos en los cuales se interactúa con el modelo. El
feature de mass assignment roles
(http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment-roles/)
es una gran mejora si se complementa con el cambio que sugirió
Santiago (config.active_record.whitelist_attributes = true). De todas
maneras lo que hay que pensar es si es responsabilidad del modelo
enumerar todas las posibles interacciones y restricciones. Creo que
sería mejor moverlo a otra capa.
***
Lo que pienso últimamente es que un modelo puede tener uno o más
workflows. Cada workflow representa una interacción, y define su
integridad de datos y transformaciones. El tema de las restricciones
no es responsabilidad del workflow, sino del contexto en donde se
ejecuta. Por ejemplo, para el workflow de "sign up", voy a validar que
el usuario sea guest. Para el workflow "update billing information"
voy a validar que el usuario esté logueado, etc. Esa validación
debería ocurrir en el controller o en algún lugar homólogo, pero no en
el workflow (como objeto) ni en el modelo.
Santiago Pastorino
> 2012/3/6 Santiago Pastorino <sant...@wyeworks.com>:
>> Sí, pero aún está en discusión ... tenés las primeras ideas en este
>> gist https://gist.github.com/1974187
>
> Estoy de acuerdo con Bruno y con quienes sugieren en los comentarios
> que es mejor algo al estilo de lo que hace Django.
Yo no estoy diciendo que no esté de acuerdo,
*** "Está en discusión" *** y si tienen buenas ideas y ganas mandenle
mensaje a Yehuda.
Bruno Deferrari
Yo ya comenté en el gist las 2 propuestas que para mi son las que encaran.
1- copiarle a django (que ya lo dijeron otros)
2- copiarle a pylons (que no lo había dicho nadie más, y que es la
dirección que va a tomar bureaucrat cuando me den las bolas para
retomarlo)
--
BD
Santiago Pastorino
Bruno Deferrari
Bueno, esto es un comienzo: https://github.com/indrekj/funky_form
Espero que no terminen metiendo el proposal de wycats solo porque es wycats.
--
BD
Instr. Dwayne Macgowan
|
Dwayne Macgowan Instructor del Método DeRose
Para conocer el Método DeRose visitá:
Blog de DeRose |
|
Bruno Deferrari
>
> seguramente de esta crisis saldrá una buena mejora para rails. ese
> funky_form se ve interesante.
>
No es exactamente lo mismo que hace Django (o las otras opciones que
hay en Python), pero creo que es una que juega bien con lo que es
Rails, ya que se basa en ActiveModel, y provee una muy al estilo de lo
que espera un usuario de Rails. Tomando en cuenta el contexto de Rails
igual es con la solución que yo iría.
> Dwayne Macgowan
>
> Instructor del Método DeRose
>
>
> Para conocer el Método DeRose visitá:
>
> Blog de DeRose
> Entrevista a DeRose, Entrevista a Edgardo Caramella
> Demostración de Técnicas
>
>
>
>
>
>
--
BD