php - remove - strip_tags wordpress

Construir un mejor sistema de control de acceso

Question

Estoy en el proceso de construir un sistema de control de acceso como parte de un marco web que estoy desarrollando. Quiero hacerlo super flexible e impresionante. ¿Puedes ayudarme aportando información y conocimientos sobre mi diseño? Aquí está mi trabajo hasta ahora (mis preguntas específicas están en la parte inferior):

Usuarios

• Los usuarios tienen un nombre de usuario (32 caracteres, sin espacios) y contraseña
• Los usuarios tienen una o más direcciones de correo electrónico que deben ser verificadas
• Los usuarios pueden iniciar sesión usando su nombre de usuario o cualquiera de sus direcciones de correo electrónico
• Los usuarios pueden estar asociados a cero o muchas cuentas.

Cuentas

• Las cuentas representan uno o más usuarios
• Cada usuario puede tener permisos o roles específicos para una cuenta (por ejemplo, el propietario de la cuenta o "puede agregar un nuevo usuario")
• Todas las cuentas están vinculadas a un tipo de cuenta

Tipos de cuenta

• Los tipos de cuenta tienen cero o muchos roles de tipo de cuenta
• Los tipos de cuenta tienen cero o muchas características de tipo de cuenta

Tipo de cuenta Roles

• Por ejemplo, "Propietario", "Administrador", "Usuario avanzado", "Invitado", etc.
• Los roles de tipo de cuenta son una colección de permisos de tipo de cuenta

Permisos de tipo de cuenta

• Los permisos de tipo de cuenta son acciones específicas en el sistema contra las cuales se verificará la lógica de la aplicación.
• Pueden hacer referencia a un padre, por lo que pueden ser agrupados jerárquicamente
• P.ej:
  • "Gestión de usuarios"
    • "Agregar usuario"
    • "Eliminar usuario"
• Estos permisos pueden ser específicamente para una característica de tipo de cuenta

Características del tipo de cuenta

• Las características de tipo de cuenta pueden activarse en una cuenta para otorgarle más permisos
• Por ejemplo, "Cuenta Estándar" o "Cuenta Premium"
• Estas funciones, si están activadas en una cuenta, le darán al propietario de la cuenta un mayor acceso al sistema
• Se rastrean cuando se activan o desactivan y se pueden facturar periódicamente o a pedido

Preguntas

¿Cuál es la mejor manera de que la lógica de la aplicación compruebe una acción del usuario? Estaba pensando en almacenar todos los permisos de un usuario en un objeto para su sesión (lo que requeriría un cierre de sesión / inicio de sesión para actualizar los permisos, del cual no soy un fanático: ¿alguna idea sobre la administración de permisos en tiempo real?):

{
"All Permissions": {
"User Management": {
"Add User",
"Delete User"
},
"Premium Account": {
"Download Files",
"Upload Files"
},
}
}

Luego declararía los permisos que son necesarios para una acción específica en el sistema. Quizás algo como:

Permission::require(''Add User'');

Si los permisos declarados no estuvieran en el objeto de permiso de los usuarios, la solicitud fallaría. Sin embargo, esto parece un poco intenso para la acción de cada usuario. Además, ¿qué sucede si otro subconjunto de permisos tiene la cadena "Agregar usuario"?

Gracias de antemano por cualquier ayuda con esto!

Answer 1

Aquí está mi sentido, por lo que vale.

Primero diría, cuando comience a diseñar esto, piense en la POO y cómo se aplicaría a las entidades dentro del sistema. Usuarios, rol de usuario, roles, permisos de rol, cuentas, tipos de cuenta, tipo de cuenta, etc.

USUARIOS: - Debería permitirse el uso de OpenID ya que está ganando terreno - La opción de seleccionar entre una ID o UUID para la portabilidad de la base de datos

ROLES DE USUARIO: (no son ROLES DE TIPO DE CUENTA) Lo invito a ser muy específico aquí. Por ejemplo, ¿dónde traza la línea entre el usuario avanzado y el administrador? ¿Cuál es la diferencia entre ADMIN y PROPIETARIO? Mientras estos estén claramente definidos (y no borrosos), entonces funcionará. Si hay alguna pregunta entre su base de usuarios, pronto tendrá un conjunto complicado de roles y permisos. Mantendría esto al mínimo para mantener las cosas limpias. Los usuarios descubrirán cómo trabajar con lo que se les da. Además, cambiaría esto a ROLES DE TIPO DE USUARIO. Los roles deben aplicarse al usuario, no a la cuenta.

PERMISOS DE FUNCIÓN: (no PERMISOS DE TIPO DE CUENTA) Esto debe cambiarse a PERMISOS DE FUNCIÓN. Los permisos se extienden a la función de un usuario, no a una cuenta o un usuario. En mi experiencia, cuanto más claro está el diseño, menos espacio hay para la confusión en el camino. Además, evita el ACL como la plaga. Haz que sea una relación uno a uno simple. Todavía tengo que encontrar una razón para implementar ACL para cualquier sistema basado en web. Otros sistemas basados ​​en permisos son mucho más fáciles de entender, mantener y usar. No tiene sentido complicar el asunto.

CARACTERÍSTICAS DEL TIPO DE CUENTA: Tenga cuidado de no ocultar los Permisos de Tipo de Cuenta y las Características de Tipo de Cuenta. Su primer punto de bala utiliza los permisos de palabra. Cambiarlo a características. El tipo de cuenta activará funciones más avanzadas / premium (no permisos).

Gestión de permisos: para una aplicación sin estado que se ejecuta en la web, las sesiones son el camino a seguir. La ventaja es que no hay viajes de ida y vuelta al DB para verificar constantemente si un usuario está autorizado.

Permission::require() embargo, Permission::require() debería seguir las mismas definiciones de parámetros que las sesiones. Esto evitará la superposición de otros subconjuntos de permisos. Por lo tanto, la llamada sería algo como Permission::require(''User Management'', ''Add User''); Esto significa que buscaría $_SESSION[''All Permissions''][''User Management''][''Add User''] Esto evitará la ambigüedad.

Recuerda que SIMPLE es MEJOR.

Answer 2

Eche un vistazo aquí http://www.sqlrecipes.com/database_design/fine_grained_role_based_access_control_rbac_system-3/

Los conceptos son básicamente los mismos y es agradable de usar y considerablemente rápido para un control de acceso realmente preciso.

Answer 3

La semántica que estás usando es un poco confusa. Por ejemplo, los tipos de cuenta de "Propietario", "Administrador", "Usuario avanzado", "Invitado" se parecen más a "Tipos de usuario".

Además, quizás pueda hacer que las cosas que llama "AccountPermissions" sean una subclase de Account. De esta manera, dependiendo del tipo de cuenta, se aplicarán diferentes permisos.

Answer 4

Me gustaría echar un vistazo al sistema de Java para los permisos:

http://download.oracle.com/javase/6/docs/api/java/security/Permission.html

Utiliza "lógica de implicación"; es decir, el objeto de permiso es lo que decide si se permite la acción dada (es decir, si los permisos "implican" acceso a un recurso). También revisaría el permiso de acceso básico ya que tiene una especificación de espacio de nombres bastante simple para los permisos. En su ejemplo sería (siguiendo la nomenclatura CRUD)

• usuario.crear
• usuario.delete
• file.read
• archivo.create

En nuestra aplicación web, asignamos un permiso a cada recurso o procedimiento que se puede solicitar, y un conjunto de permisos a cada usuario. Entonces hacemos un

boolean isAuthorized = user.permissions.implies (requiredResource.permission); (encapsulación estándar implícita)

para determinar si el usuario tiene permitido el acceso.

Answer 5

Mirando los Permisos de Tipo de su Cuenta, parece que tiene en mente un diseño de sistema de estilo de Lista de Control de Acceso (ACL).

Si quieres que sea súper flexible y asombroso, sugiero que este no es un buen diseño. El trabajo del sistema ACL para permisos simples, y tal vez en realidad esté bien en su escenario, pero tan pronto como las reglas para otorgar permisos se vuelvan dinámicos, es decir, confiar en cualquier dato contextual más allá de la identidad o roles del usuario: la caída de ACL plano rapido

Este video incluye algunos detalles sobre los fallos de las ACL y analiza formas alternativas de implementar el control de acceso que se ocupa de situaciones reales.

Además, esto se ha hecho antes (aunque sorprendentemente hay muy poco para las implementaciones que podemos ver); Tal vez echar un vistazo a la seguridad de Rhino . El enlace original http://ayende.com/Blog/category/548.aspx está roto, por lo que se mantiene el enlace del archivo de Internet como referencia.

Answer 6

No tengo ningún consejo específico, pero dos sistemas con los que estoy familiarizado y que tienen muy buenos sistemas flexibles de acceso / permiso son Drupal y Plone. Podría hacer mucho peor que copiar cómo funciona cualquiera de ellos. Han tenido años de pruebas en el mundo real detrás de ellos.

Answer 7

Te aconsejo que busques en Zend_Acl desde Zend Framework. Como la mayoría de los paquetes Zend, tiene una curva de aprendizaje empinada. Pero cuando capta completamente el recurso, la acción, la relación de rol, se convierte en una base versátil y poderosa para sus propias implementaciones de ACL.

Investigue un poco sobre los paquetes y patrones existentes de ACL.

Answer 8

Una forma que he visto que me gusta es una especie de permisos "en cascada". Tiene un conjunto central de permisos, digamos leer, escribir, eliminar, y esos pueden asignarse a un grupo o usuario.

READ USER1
READ USER2
WRITE USER2
READ USER3
WRITE USER3
DELETE USER3

Alternativamente, puede especificar un "grupo" en lugar de un nombre de usuario.

READ SUBSCRIBER
READ EDITOR
READ ADMIN
WRITE EDITOR
WRITE ADMIN
DELETE ADMIN
USER1 SUBSCRIBER
USER2 EDITOR
USER3 ADMIN

Y luego puede simplemente usar los valores de la tabla para ordenar y buscar registros. Esto permite la flexibilidad de ser miembro de varios grupos con permisos mutuamente exclusivos, etc.

Answer 9

Zed Shaw tenía algunas cosas interesantes que decir sobre las ACL y sus limitaciones. Definitivamente vale la pena verlo antes de seguir por esta ruta.

http://vimeo.com/2723800