estoy cambiantes código de una aplicación construida en un marco PHP personalizado no estándar en Ruby on Rails (versión 3). En la versión de PHP todos los controladores son realmente gordos, con modelos delgados, con los que siempre he estado en desacuerdo, así que disfruto la forma en que Rails hace la validación a nivel de modelo, que es probablemente el 90% de lo que está sucediendo en estos reguladores de grasa actualmente.validación Carriles 3 ActiveRecord basado en permisos de usuario
Uno de los problemas que se me presentan, y no está seguro de cómo resolver sin embargo, es el de las diferentes reglas de validación sobre la base de que está haciendo el cambio en el modelo. Por ejemplo, un administrador o el creador original del registro debería poder hacer cosas como marcar un registro como eliminado (eliminación suave) mientras que los demás no deberían hacerlo.
class Something < ActiveRecord::Base
...
validates :deleted, :owned_by_active_user => true
...
end
class OwnedByActiveUserValidator < ActiveModel::EachValidator
validate_each(record, attr_name, attr_value)
# Bad idea to have the model know about things such as sessions?
unless active_user.admin? || active_user.own?(record)
record.errors.add :base, "You do not have permission to delete this record"
end
end
end
Dado que el modelo en sí es (en teoría) desconocen el usuario que está realizando el cambio, lo que es el "carriles manera" de hacer este tipo de cosas? ¿Debo configurar el usuario activo como un atributo virtual en el registro (no realmente guardado en la base de datos), o debería simplemente realizar estas comprobaciones en el controlador? Tengo que admitir que es extraño que el modelo verifique los permisos del usuario activo y agrega complejidad cuando se trata de probar el modelo.
Una de las razones por las que deseo mantener todo esto en el modelo es porque quiero proporcionar tanto una API (a la que se accede por OAuth) como un sitio web, sin duplicar demasiado código, como estos tipos de controles de permisos.
Gracias, tengo que estar de acuerdo con usted. Mis modelos deben hacer lo que se les ordena (siempre que la lógica comercial lo permita). Mis controladores deberían decidir quién les dice. Solo me aseguraré de abstraer los detalles sangrientos lo mejor que pueda. – d11wtq
dogma ... sé que esto es como se hace comúnmente, pero me parece que la puesta de control de acceso en los modelos es directamente una solución elegante si se tiene en cuenta los modelos que sea su nivel de API regla de datos/negocio. También evita repetir la misma información en múltiples controladores que tocan el mismo modelo.Y el uso de validadores para este fin también parece muy conveniente: puede generar errores como "lo siento, no tienes permiso para editar ese campo". Sin embargo, ese campo no debería haber sido mostrado en primer lugar. Ojalá hubiera una solución que permitiera la introspección para los constructores de formularios. – odigity
Puede crear clases de modelo de formulario (no respaldado por base de datos) que implementen la validación y los métodos necesarios para el generador de formularios. – yfeldblum