Forum: Rails-ES Renderizar vistas según tu nivel de usuario

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Carlos B. (Guest)
on 2009-04-20 19:42
Veréis, quiero aprovechar los scaffolds que me genera Rails y la
identificación de usuarios para no estar creando acciones y
controladores independientes para la vista de administración y para la
de usuario, es decir, quiero que cuando un administrador se conecte al
sitio aparezcan todos los link_to a todas las acciones que se puedan
realizar en la página (el administrador por tanto vería la aplicación
entera) y que el usuario sólo pueda ver las que yo permita.

Imagínense un ejemplo sencillo como es un scaffold, deseo que si un
administrador está logueado pueda acceder a todas las acciones y sin
embargo si se ha detectado un usuario normal sin privilegios sólo pueda
acceder a la de show.

¿Cómo puedo llevar esto a cabo?
Agustin V. (Guest)
on 2009-04-20 19:46
(Received via mailing list)
Fijate estos screencasts de Ryan B. que muestran una forma de
organizar
lo que necesitas:


http://railscasts.com/episodes/19-where-administration-goes
http://railscasts.com/episodes/20-restricting-access
http://railscasts.com/episodes/21-super-simple-aut...

plantean una forma simple de autenticacion pero lo podes modificar de
forma
muy facil para que se haga con algun plugin de autenticacion general, lo
importante de estos screencasts es ver como cambia lo que se visualiza
segun
el user o nivel de acceso.
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Carlos B. (Guest)
on 2009-04-20 20:27
Agustin Viñao wrote:
> Fijate estos screencasts de Ryan B. que muestran una forma de
> organizar
> lo que necesitas:
>
>
> http://railscasts.com/episodes/19-where-administration-goes
> http://railscasts.com/episodes/20-restricting-access
> http://railscasts.com/episodes/21-super-simple-aut...
>
> plantean una forma simple de autenticacion pero lo podes modificar de
> forma
> muy facil para que se haga con algun plugin de autenticacion general, lo
> importante de estos screencasts es ver como cambia lo que se visualiza
> segun
> el user o nivel de acceso.
> ___________________
>       Agustin Viñao
> www.agustinvinao.com
>  agustinvinao (Skype)
>
>
> 2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>

Estoy usando authlogic, con crear un campo booleano para el usuario que
sea falso si no es administrador y verdadero si sí lo es, podría
implementarlo ¿No?

Gracias ;).
Agustin V. (Guest)
on 2009-04-20 20:31
(Received via mailing list)
Depende de como tenes armada la aplicacion, generalmente eso se hace por
una
definicio de rol para el usuario (con algun plugin por ejemplo) y asi
tener
algun helper por ejemplo para preguntar si es admin, como veras en los
screencast vas a tener un helper que con preguntar:

<%if admin?%>
<div>Eliminar...</div>
<%>end%>

podras manejar lo que vas a mostrar o no.

En tal caso si queres manejar con un flag en el modelo de usuarios,
armas un
metodo para preguntar

<%if user.admin?%>
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Guillermo (Guest)
on 2009-04-20 21:24
(Received via mailing list)
Una aproximación que podría ser más chula podría ser algo como
#/helpers/application_helper.rb
module ApplicationHelper
  def for_admin
    current_user.admin? ? yield : nil
  end
end


# En la vista
<%= for_admin{ link_to 'Borrar', borrar_model_path(model)} %>

# O en modo bloque
<% for_admin do %>
<%= link_to 'Borrar', borrar_modelo_path(modelo) %>
<% end %>


Aviso, no lo he probado, pero salvo error, debería funcionar, y parece
una
manera bastante limpia si es exactamente lo que necesitas.

Un Saludo

--
Guillermo Álvarez

Sent from Madrid, Comunidad de Madrid
Carlos B. (Guest)
on 2009-04-20 21:24
Agustin Viñao wrote:
> Depende de como tenes armada la aplicacion, generalmente eso se hace por
> una
> definicio de rol para el usuario (con algun plugin por ejemplo) y asi
> tener
> algun helper por ejemplo para preguntar si es admin, como veras en los
> screencast vas a tener un helper que con preguntar:
>
> <%if admin?%>
> <div>Eliminar...</div>
> <%>end%>
>
> podras manejar lo que vas a mostrar o no.
>
> En tal caso si queres manejar con un flag en el modelo de usuarios,
> armas un
> metodo para preguntar
>
> <%if user.admin?%>
> ___________________
>       Agustin Viñao
> www.agustinvinao.com
>  agustinvinao (Skype)
>
>
> 2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>

He estadomirando el plugin rails-authorization-plugin pero no entiendo
muy bien como utilizar el plugin ya que no sé como se aplican los roles
a los usuarios, ¿Conoces de algún tutorial para cogerle el tranquillo?
Carlos B. (Guest)
on 2009-04-20 21:37
Guillermo wrote:
> Una aproximación que podría ser más chula podría ser algo como
> #/helpers/application_helper.rb
> module ApplicationHelper
>   def for_admin
>     current_user.admin? ? yield : nil
>   end
> end
>
>
> # En la vista
> <%= for_admin{ link_to 'Borrar', borrar_model_path(model)} %>
>
> # O en modo bloque
> <% for_admin do %>
> <%= link_to 'Borrar', borrar_modelo_path(modelo) %>
> <% end %>
>
>
> Aviso, no lo he probado, pero salvo error, debería funcionar, y parece
> una
> manera bastante limpia si es exactamente lo que necesitas.
>
> Un Saludo
>
> --
> Guillermo Álvarez
>
> Sent from Madrid, Comunidad de Madrid

Sí, esa forma me parece más limpia para ahorrarme código lógico en las
vistas, dado que realmente los únicos roles en mi aplicación son el
administrador y los usuarios ¿Ves necesario usar un plugin de
autorización o mejor usar el recurso del booleano en el User?
Agustin V. (Guest)
on 2009-04-20 21:52
(Received via mailing list)
EL problema que veo de presentar un campo booleano es que estas
"ensuciando"
la informacion del usuario por llamarlo de alguna manera, hoy tenes 2
roles
posibles, pero puede que despues se te agregue alguno mas, o mismo si
podes
plantear roles en forma independiente, solo definir roles para aquellos
usuarios que sean admins nada mas.

Algo rapido que encontre en google es:
http://blog.gingertech.net/2008/05/21/rails-author...

Fijate tambien que en el repositorio del plugin tenes ejemplos de
codigos:
http://github.com/DocSavage/rails-authorization-pl...

Donde la primer linea dentro del controller define que roles son
permitidos
y una vista accesible para el resto:

permit "rubyists and wanna_be_rubyists", :except => :public_page

mismo tenes un codigo para disponer de helpers para toda la aplicacion
basados en el plugin:
http://www.botvector.net/2008/06/authorization-plu...

Espero te sirva.
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Guillermo (Guest)
on 2009-04-20 21:52
(Received via mailing list)
2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>

> ¿Ves necesario usar un plugin de
> autorización o mejor usar el recurso del booleano en el User?


Esa decesisión te corresponde a ti y tus necesidades. Si como dices un
admin
es un user normal con el flag de admin, admin corresponde a un flag.

Creas el campo admin, y ya está. Si algún día necesitas más... ya lo
cambiarás.

Rails es la máxima expresión del carpe diem llevada a la programación.

--
Guillermo Álvarez

Sent from Madrid, Comunidad de Madrid
Agustin V. (Guest)
on 2009-04-20 21:59
(Received via mailing list)
Guillermo entiendo tu opinion, pero tambien hay que resaltar que cuando
armamos una aplicacion, hay ciertas decisiones que van mas alla de la
sola
implementacion de un parecer en un instante del desarrollo, como
comentaba
en otra respuesta, por acumular atributos en un modelo para definir
pequeñas
cosas a medida que las vamos diseñando, podemos terminar con un problema
de
performance a medida que crece la aplicacion.

Siempre considero que hay ciertas lineas de desarrollo a seguir cuando
estamos armando una aplicacion, que van mas alla de si es algo muy
pequeño o
no.

Por ejemplo, saber que si estamos hablando de roles de los usuarios, por
mas
que en un instante tengamos solo 2 roles posibles, saber que el dia de
mañana si en alguna parte de la aplicacion tenemos problemas con esto,
saber
que el manejo de roles se maneja independientemente al usuario, es diria
en
resumen, una buena metodologia de saber organizar nuestro desarrollo.

O por ejemplo, como comenta Ryan B. en un screencasts [1] de no hacer
un
mass assignment, si dejamos que el flag admin se setee en el usuarios,
cualquier caso en donde se produzca un problema de seguridad con el
modelo
user, cualquiera puede tomar control de la aplicacion

[1] http://railscasts.com/episodes/26-hackers-love-mas...
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Guillermo <removed_email_address@domain.invalid>
Carlos B. (Guest)
on 2009-04-20 22:14
Agustin Viñao wrote:
> Guillermo entiendo tu opinion...
>
> [1] http://railscasts.com/episodes/26-hackers-love-mas...
> ___________________
>       Agustin Viñao
> www.agustinvinao.com
>  agustinvinao (Skype)
>
>
> 2009/4/20 Guillermo <removed_email_address@domain.invalid>

Pero tengo un problema, a ver, a la hora de registrar usuarios, ellos no
pueden elegir si son administradores o no (como es lógico), entonces
¿Cómo asigno al usuario que yo decida que sea administrador dicho rol?
Agustin V. (Guest)
on 2009-04-20 22:16
(Received via mailing list)
para asignar los perfiles, lo haras con un usuario con perfil admin, es
decir, tendras dentro de la misma aplicacion, para el usuario con perfil
admin un panel de control donde gestionar ese tipo de cosas.
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Carlos B. (Guest)
on 2009-04-20 22:20
Agustin Viñao wrote:
> para asignar los perfiles, lo haras con un usuario con perfil admin, es
> decir, tendras dentro de la misma aplicacion, para el usuario con perfil
> admin un panel de control donde gestionar ese tipo de cosas.
> ___________________
>       Agustin Viñao
> www.agustinvinao.com
>  agustinvinao (Skype)
>
>
> 2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>

Sí, pero mi duda es, si no puedo guardar en mi base de datos quién es
administrador ¿Cómo consigo declarar quién será mi primer administrador?
Agustin V. (Guest)
on 2009-04-20 22:25
(Received via mailing list)
Lo que podes armar, por ejemplo, es que una vez construida toda la
aplicacion, en la instalacion/deploy de la misma, te genere un usuario
administrador por default en la base de datos por medio de una
migracion. Al
fin de cuentas, el usuario admin puede ser un insert en users y roles.

Asi hacen la mayoria de los sistemas uno instala, ponen un usuario
automatico o sino te piden los datos d ese user en la isntalacion. Yo
considero que con crear un user en la instalacion/deploy alcanza.
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Carlos B. (Guest)
on 2009-04-20 22:32
Agustin Viñao wrote:
> Lo que podes armar, por ejemplo, es que una vez construida toda la
> aplicacion, en la instalacion/deploy de la misma, te genere un usuario
> administrador por default en la base de datos por medio de una
> migracion. Al
> fin de cuentas, el usuario admin puede ser un insert en users y roles.
>
> Asi hacen la mayoria de los sistemas uno instala, ponen un usuario
> automatico o sino te piden los datos d ese user en la isntalacion. Yo
> considero que con crear un user en la instalacion/deploy alcanza.
> ___________________
>       Agustin Viñao
> www.agustinvinao.com
>  agustinvinao (Skype)
>
>
> 2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>

Ajá, muchas gracias, ¿Mientras para probar la aplicación cargo el
usuario con una fixture por ejemplo?
Agustin V. (Guest)
on 2009-04-20 22:39
(Received via mailing list)
Lo que podes armar es una migracion exclusiva para insertar ese
registro:

script/generate migration admincreate

y en la migracion podes hacer algo como:

user.create(:username => 'admin', :password => 'secret')
user.role.create(:rol_id => 1)

user.save


PD: pongo los codigos para hacer el ejemplo digamos.
Este es un ejemplo de una migracion que arme en una app para agregar un
campo
class Borradornotas < ActiveRecord::Migration
  def self.up
    add_column :notas, :borrador, :string, :limit=>1, :default=>"0"
    *Nota.update_all('borrador=0') *
  end

  def self.down
    remove_column :notas, :borrador
  end
end
fijate que en la linea en negrita hago un update de todas las notas
anteriores para que quede bien el campo que le estoy agregando que tiene
un
valor default, en las migracion se puede hacer operaciones de cualquier
tipo
con los registros.
___________________
      Agustin Viñao
www.agustinvinao.com
 agustinvinao (Skype)


2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
Guillermo (Guest)
on 2009-04-20 23:09
(Received via mailing list)
2009/4/20 Carlos Belizón <removed_email_address@domain.invalid>
>
> Pero tengo un problema, a ver, a la hora de registrar usuarios, ellos no
> pueden elegir si son administradores o no (como es lógico), entonces
> ¿Cómo asigno al usuario que yo decida que sea administrador dicho rol?
>

Pues yo lo suelo hacer a mano en la base de datos.

Y como bien comenta Agustin, para evitar los mass_assigments, recuerda
poner
como protegido el atributo admin.

class User < AR:Base
  attr_protected :admin
end


Aunque yo soy más de listas blancas con attr_accesible.
Guillermo (Guest)
on 2009-04-20 23:18
(Received via mailing list)
2009/4/20 Agustin Nicolas Viñao Laseras <removed_email_address@domain.invalid>

> Guillermo entiendo tu opinion, pero tambien hay que resaltar que cuando
> armamos una aplicacion, hay ciertas decisiones que van mas alla de la sola
> implementacion de un parecer en un instante del desarrollo, como comentaba
> en otra respuesta, por acumular atributos en un modelo para definir pequeñas
> cosas a medida que las vamos diseñando, podemos terminar con un problema de
> performance a medida que crece la aplicacion.


Por eso decía que la solución es cosa suya según sus necesidades.

Tal vez haya entendido mal el desarrollo ágil, metodología que me gusta
bastante. Me gustan pequeñas iteraciones sobre el producto, una
interacción
a grandes rasgos resuelve los problemas de esa iteración. Y no se hacen
planes a largo plazo. ¿Por qué voy a complicar una cosa con roles si con
decir que el admin es el que tiene el primer id, o si hay varios, añadir
el
campo de admin?

Cuando tenga problemas de rendimiento. Pues añado índices a la base de
datos, cuando vuelva a tener problemas, añado caches de vista/modelo,
etc...
Y cuando se me quede corta la máquina, añado otra máquina y pongo un
balanceador. Pero no me gusta caer en la optimización prematura,
optimizar
un producto, que todavía no se como va a ser.

Pero insisto es simplemente como me gusta desarrollar, lo que entiendo
yo
como desarrollo agil, que casi podría resumir en resolver los problemas
inmediatos que tengo. El futuro ya vendrá.


Siempre considero que hay ciertas lineas de desarrollo a seguir cuando
> estamos armando una aplicacion, que van mas alla de si es algo muy pequeño o
> no.


Perfecto. Eso lo veía mucho en desarrollo Java, cuando un producto tenía
que
estar muy definido antes de empezar la parte de diseño del modelo de
negocio
y antes incluso de ponerse a programar. Pararse a pensar todos los ´y
si...´
que pudiese tener la aplicación.


Por ejemplo, saber que si estamos hablando de roles de los usuarios, por
mas
> que en un instante tengamos solo 2 roles posibles, saber que el dia de
> mañana si en alguna parte de la aplicacion tenemos problemas con esto, saber
> que el manejo de roles se maneja independientemente al usuario, es diria en
> resumen, una buena metodologia de saber organizar nuestro desarrollo.


Bueno, para ti, será la buena. Para mí, insisto que no, y te pido que
respetes lo que yo creo que es bueno para mi o no. Para mi esa
metodolgía,
en desarrollo web, un desarrollo de un producto dinámico, incluso una
start-up, es totalmente erróneo. Hago la aplicación Diciendo que el
usuario
con id 1 sea el admin. Cuando necesite algo más... hago la migración y
creo
la columna admin. Necesito algo más y creo los roles. Pero como producto
dinámico que es... ¿Y si no necesito roles? ¿Por que voy a preocuparme
por
algo que todavía no ha llegado?



> O por ejemplo, como comenta Ryan B. en un screencasts [1] de no hacer un
> mass assignment, si dejamos que el flag admin se setee en el usuarios,
> cualquier caso en donde se produzca un problema de seguridad con el modelo
> user, cualquiera puede tomar control de la aplicacion


Efectivamente, si no sabes lo que es el mass_assigment ni como usarlo,
no lo
uses. Si lees la documentación de rails verás el attr_protected y
attr_accesible que implementa el paradigman de listas negras y listas
blancas sobre los parámetros del modelo.


[1] http://railscasts.com/episodes/26-hackers-love-mas...
>

 Lo siento, pero en cuanto a la seguridad sobre rails, no suele ver
posts de
2007.
This topic is locked and can not be replied to.