2008-10-04 11 views
5

Las aplicaciones de publicación y/o colaborativas a menudo implican compartir el acceso a los recursos. En un portal, un usuario puede tener acceso a cierto contenido como miembro de un grupo o por acceso explícito. El conjunto completo de contenido podría incluir contenido público, contenido de membresía grupal y contenido de usuario privado. O bien, con aplicaciones colaborativas, es posible que deseemos transferir recursos como parte de un flujo de trabajo o compartir la custodia de un documento para fines de edición.¿Cuáles son las mejores prácticas en cuanto a la autorización de la lista de recursos?

Dado que la mayoría de las aplicaciones almacenan estos recursos en una base de datos, normalmente se crean consultas como 'Obtener todos los documentos que puedo editar' o 'Obtener todo el contenido que puedo ver'. Donde 'puede editar' y 'puede ver' son los privilegios del usuario.

Tengo dos preguntas:

  1. Es muy fácil para autorizar al usuario una vez que se ha recuperado un recurso, pero ¿cómo se realice de manera eficiente autorización en la lista de los recursos disponibles? Y,

  2. ¿Se puede separar este tipo de autorización del núcleo de la aplicación? Tal vez en un servicio separado? Una vez separados, ¿cómo se pueden filtrar las consultas como 'Obtener todos los documentos que puedo ver con título como [SomeSearchTerm]'? Me parece que su sistema separado tendría que copiar una gran cantidad de datos de referencia.

Respuesta

0

por lo general tienen un esquema como éste

Usuarios − − ∈ UserDocuments ∋ − − los documentos de la

Entonces crea una vista "ProfiledDocuments"

SELECT <fields> 
FROM Documents d 
INNER JOIN UserDocuments ud on ud.DocumentId = d.Id 
INNER JOIN Users u ON u.Id = ud.UserId 

A continuación, ejecute la búsqueda consultas en ProfiledDocuments siempre utilizando un archivo UserId er. Con los índices apropiados, funciona bastante bien.

Si necesita permisos más complejos, puede hacerlo con un campo adicional en la tabla de muchos a muchos de UserDocuments que especifica el tipo de permiso.

0

Aunque su pregunta está bastante elaborada, en realidad falta algo de contexto.
¿Qué define los documentos para los que un usuario tiene privilegios? ¿Puede un usuario editar solo sus "propios" archivos? ¿Hay algún mecanismo basado en roles aquí? ¿Está más orientado a MAC (es decir, un usuario puede ver un nivel de seguridad)? ¿Existe un atributo definitorio para los datos (por ejemplo, departamento)?

Todas estas preguntas juntas pueden dar una mejor imagen y permitir una respuesta más específica.

Si los documentos son "propiedad" de un usuario específico, es bastante sencillo: tiene un campo "propietario" para el documento. Luego, consulta todos los documentos que posea el usuario.
Del mismo modo, si puede predefinir la lista de usuarios (o roles) nombrados que tienen acceso, puede consultar una lista unida entre los documentos, la lista de usuarios/roles autorizados y el usuario (o sus roles) .
Si un usuario obtiene permisos de acuerdo con su departamento (u otro atributo de documento similar), puede consultar sobre eso.
Del mismo modo, puede consultar todos los documentos con un nivel de seguridad igual o inferior al de los privilegios del usuario. Si se trata de un flujo de trabajo dinámico, cada documento normalmente debe estar marcado con su estado actual y/o el siguiente paso esperado; qué usuarios pueden realizar ese siguiente paso es simplemente otro privilegio/rol (tratar lo mismo que arriba).
Entonces, por supuesto, querrá hacer un UNION ALL entre todos esos y documentos públicos ...

Por cierto, si no lo he dejado claro, esto no es un problema simple - hazte un favor y encuentre la infraestructura preconstruida para hacerlo por usted. Incluso a costa de simplificar sus esquemas de autorización.

5

Le puede interesar leer this article by Steffen Bartsch. Resume todos los complementos de autorización para Ruby on Rails, y estoy seguro de que lo ayudará a encontrar su solución (aunque este artículo trata sobre los complementos de Rails, los conceptos son fácilmente exportables fuera de Rails).

Steffen también construyó su propio plugin, llamado "declarativa Autorización", que parece coincidir con sus necesidades, en mi humilde opinión:

  • , por un lado, se define papeles (como "visitante", "admin "...). Sus usuarios están asociados a estos roles (en una relación muchos a muchos). Asigna estos roles a privilegios (de nuevo en una relación muchos a muchos). Cada privilegio está vinculado a un contexto dado . Por ejemplo, la función "visitante" puede tener el privilegio "leer documentos". En este ejemplo, "lea" es el privilegio y se aplica al contexto "documentos".
    • Nota: en el complemento de Steffen, puede definir una jerarquía de roles. Por ejemplo es posible que desee tener el papel "global_admin" incluir el papel "document_admin", así como el papel "comment_admin", etc.
    • También puede define jerarquías de privilegios: por ejemplo, la "gestionar" privilegio podría incluir la " leer", "actualización ", "añadir " y "borrar " privilegios.
  • , por otro lado, que codifique la aplicación de pensar en términos de privilegios y contextos, no en términos de roles. Por ejemplo, la acción para mostrar un documento solo debe verificar si el usuario tiene el privilegio de "leer" en el contexto "documentos" (no es necesario verificar si el usuario tiene el rol "visitante" o cualquier otro rol). Esto simplifica enormemente su código, ya que la mayoría de la lógica de autorización se extrae en otro lugar (y tal vez incluso sea definida por otra persona).

Esta separación entre la definición de los roles de usuario y la definición de los privilegios de nivel de aplicación garantiza que su código no cambiará cada vez que defina un nuevo rol.Por ejemplo, aquí es cómo es simple el control de acceso se vería en un controlador:

class DocumentController [...] 
    filter_access_to :display, :require => :read 
    def display 
    ... 
    end 
end 

Y dentro de un punto de vista:.

<html> [...] 
    <% permitted_to?(:create, :documents) do %> 
    <%= link_to 'New', new_document_path %> 
    <% end %> 
</html> 

plug-in de Steffen permite también a nivel de objeto (es decir, de fila nivel) control de acceso. Por ejemplo, es posible que desee definir una función como "document_author" y darle "gestionar" privilegio "en documentos", pero solamente si el usuario es el autor del documento. La declaración de esta regla probablemente sería así:

role :document_author do 
    has_permission.on :documents do 
    to :manage 
    if_attribute :author => is {user} 
    end 
end 

¡Eso es todo! Ahora puede obtener todos los documentos que se le permite al usuario actualizar como esto:

Document.with_permissions_to(:update) 

Desde el "gestionar" privilegio incluye el privilegio "actualización", esto devolverá la lista de documentos cuyo autor es el usuario actual.

Por supuesto, no todas las aplicaciones necesitarán este nivel de flexibilidad ... pero las suyas podrían.

Cuestiones relacionadas