Quantcast
Channel: Blog Oficial de Wixet » Novedades
Viewing all articles
Browse latest Browse all 4

Sistema de permisos listo

0
0

Wixet es como la navidad, aparece una vez cada año. Saludos, la verdad es que no me gusta publicar cualquier nimiedad y esto provoca que parezca un blog abandonado, aunque quizá debiera utilizar el twitter. Vayamos con lo importante. Quiero anunciar que después de mucho trabajo está listo el sistema de permisos de Wixet. Básicamente permite gestionar los permisos sobre recursos tanto a perfiles como a grupos de perfiles. Bien, explico un poco esto. Antes quiero decir que la se ha tratado de realizar el sistema lo más simple posible, que no sencillo. Lo que haya salido es otra historia XD. Me gustaría destacar los siguientes puntos:

Al grano

Si no quieres tragarte todo el rollo, simplemente que está disponible en http://dev.wixet.com. De momento no se requiere email váildo ni nada, así que te puedes crear todas la cuentas que quieras para probar. Cuando se vea que la cosa no tiene demasiados fallos, estará disponible http://www.wixet.com donde sí estará la versión en “producción”.
La idea de esta versión es encontrar fallos, por lo que si no quieres tocar algo con bastantes posibilidades de fallo mejor no entres para no decepcionarte. Aun así, diré que he pasado unos tests funcionales que abarcan bastantes casos pero NO todos, además de que seguro que vuestras mentes son más ágiles para encontrar fallos (siempre es más fácil ver la paja en el ojo ajeno).

En breve enviaré una invitación a una lista de correo a todos los que me proporcionaron su email. Los motivos son que así se consigue una mejor comunicación y sobretodo que en cualquier momento la gente se puede borrar (o inscribirse) de manera automática.

Entidades en Wixet

El sistema está formado por entidades (también se podrían llamar “cosas” pero así queda más técnico :P) que son:

Perfil: Se puede entender como un usuario del sistema, las personas que acceden a los recursos. Los permisos controlan el acceso de perfiles sobre los recursos
Grupo de perfies: Agrupación de varios perfiles en una misma entidad. Un perfil puede estar en varios grupos de perfiles y todos los perfiles contenidos en él heredan sus permisos
Recurso: Cualquier cosa (incluidos los perfiles) que vive en la aplicación y puede ser compartida. Pueden ser fotos, textos (cualquier archivo) o cosas más abstractas.
Contenedor de recursos: Agrupación de varios recursos en una misma entidad. Un recurso pertenece a un y sólo un contenedor. Un contenedor de recursos es también un recurso en sí mismo.
Permisos: Un permiso está definido por cuatro propiedades booleanas (que pueden ser verdaderas o falsas): acceso permitido, acceso denegado, escritura permitida, escritura denegada.

Los permisos se asignan a perfiles (o grupos de perfiles) sobre recursos (o contenedores de recursos). Los permisos son heredados. Un perfil hereda los permisos de todos los grupos a los que pertenece de la misma manera que un recurso los hereda de su contenedor de recursos.
Es importante tener en cuenta que siempre prevalecen los permisos más restrictivos. Esto quiere decir que ante la duda, se deniega el acceso. De esta manera se elimina cualquier posible laguna que permita accidentalmente acceder a un recurso a alguien no autorizado. Entonces es cuando aparecen los
permisos explícitos e implícitos. Llamamos permisos explícitos a aquellos que existen directamente sobre un recurso. Por ejemplo, asigno al usuario X el permiso de lectura sobre el recurso Y. Llamamos permisos implícitos a aquellos que son “deducidos” ya sea por herencia o por políticas de seguridad.

En caso de ausencia de permisos, se deniega. En el caso de permisos contradictorios (por una parte de permite y por otra se deniega) se aplica el más restrictivo. Wixet sigue esta política de seguridad porque se considera que es preferible que una persona “autorizada” no acceda a un recurso (en ese caso la persona
nos informa y simplemente asignamos el permiso) a que una persona no autorizada acceda a un recurso. Muchos estarán pensado que eso ya existe y es lo que cualquier sistema decente tiene. Es cierto, el servicio es el mismo pero el contexto muy diferente como veremos en los siguientes apartados.

Implementación

No quiero aburrir con detalles técnicos así que sólo comentaré un poco por encima las posibilidades. El primer y más importante punto es que el sistema se ha diseñado para ser rápido independientemente de la cantidad de usuarios/peticiones. En un sistema estándar básico el chequeo de permisos puede ser O(n²) o peor
(piensa que tienes que mirar los permisos directos sobre el recurso y sobre el contenedor además de los permisos del usuarios y cada uno de los grupos a los que pertenece el usuario). Siempre digo que con pocos usuarios cualquier aplicación va fluida, el problema es cuando va aumentado la carga de trabajo.
Con pocos recursos o usuarios no se notarían todas las optimizaciones, pero en cuanto la cosa crezca un poco marca la diferencia. Incluso con pocos usuarios, estas optimizaciones cargan más al sistema pero al haber pocos usuarios, ni se nota por lo que se compensa :P. Considero que en una aplicación web la escalabilidad no es una opción sino un requisito. No es como un ordenador personal donde sólo se utiliza por unos pocos usuarios. Hay que tener en cuenta que cualquier recurso tiene sus permisos y como la aplicación consiste en compartir recursos cualquier mejora del rendimiento en ese área se verá gratamente compensada.

Además existe otro gran problema y es obtener sólo el contenido de un contenedor al que se tiene acceso. Por ejemplo, tengo un album (contenedor de fotos) al que se me permite el acceso, pero hay una foto (recurso) a la que se me deniega el acceso. Para soportar estos caso, el sistema debería comprobar foto a foto los permisos. Imagina que tienes 1000 fotos. Imagina que además quiere paginar esas 1000 fotos, no vale con decir “dame de la foto 20 a la 40” porque si (por ejemplo) si no tienes permiso a la foto 15 el sistema no lo sabe, a menos que también haya procesado de la 0 a la 20. Ahora imagina 10.000 usuarios haciendo lo mismo. Vamos, un desastre.

Todo esto se arregla principalmente con cachés, delegar en terceros, y “entorpecer” tareas poco usuales a cambio de acelerar las más comunes. Por ejemplo, mientras que asignar permisos en un sistema estándar de O(1) en Wixet es algo más complejo, ya que se tienen que invalidar cachés y generarlas cuando sea necesario. Sin embargo, la modificación de permisos se hace muy pocas veces y en muchas ocasiones sólo cuando se crea el recurso. En cambio, la consulta de los permisos se hace constantemente.
Con lo de delegar me refiero a dejar que otros hagan lo que saben hacer ya que lo harán mejor que yo. Es evidente que el procesamiento masivo de datos es inviable en PHP, por eso las tareas duras se realizan directamente en mysql y demás. Con una sóla consulta SQL se cruzan todos los datos para obtener los permisos, y con una sóla consulta se insertan todos los permisos. Esto no sólo ofrece velocidad sino fiabilidad ya que no se dejan cosas a medias.
Sobre las caches con los permisos precalculados tengo que decir que pueden ser enormes (dependiendo de la cantidad de perfiles y recursos). Se guarda para cada usuario los recursos a los que puede acceder junto con alguna información más. Pero esto no surge por casualidad, sino pensando en utilizarlo con sistemas como memcached o mongodb (entre otros) que son extremadamente rápidos en ese escenario. Además, no hay problema por invalidar cachés en cualquier momento pues Wixet las genera y punto. Esto es útil en los casos en los que hay archivos viejos que no han sido accecidos en meses. Pero no tanto por el espacio (aunque sí el sistema de caché se almacena en memoria sí) que ocupe, sino por lo que pueda entorpecer las búsquedas. Recuerdo que estoy hablando de escenarios con millones de usuarios.

Hay muchos más detalles y buscar una solución equilibrada es complicado, principalmente porque no existe una solución perfecta y hay que decidir qué es lo que mejor se ajusta a las necesidades.

Finalidad

Como ya he dicho en otras ocasiones, Wixet es simplemente un “motor” de red social que facilita las tareas más comunes como es la compartición de recursos o la gestión de usuarios. No obstante, también he desarrollado una interfaz gráfica que utiliza Wixet (de manera muy básica) que ya sería una red social completa (aunque muy muy sencilla) y es precisamente lo que venía a presentar hoy. Con bastante probabilidad la aplicación que he creado con Wixet no te guste, pero no hay problema, siempre puedes hacer la tuya propia. Ya existen otras soluciones bastante buenas a una red social, el problema es que todas ellas te ofrecen algo completo que o lo tomas o lo dejas. Además, es imposible hacer una super red social ideal y perfecta para todo, si lo intentas sólo sacarás un engendro que no será útil para nadie. Por ejemplo, entre una red social para aficionados a las fotos, otra dedicada a la música o una dedicada a la enseñanza sólo comparten las necesidades más básicas, que es compartir cosas. Y eso es precisamente lo que ofrece Wixet, una herramienta para compartir cosas con un control total de lo que se comparte.

Creo que la idea está bien y a mi por lo menos me parece interesante y me gustaría haber tenido algo así.

Sobre la interfaz gráfica

La interfaz está creada con backbone.js + jquery + bootstrap de twitter + google closure. He aprendido a utilizar la mayoría de esas herramientas mientras hacía la interfaz así que hay secciones que debería “reconstruir”. Por eso os pido que no me tengas en cuenta si ves alguna aberración en esa zona 😛
También tengo que decir que NO está terminada, básicamente permite la gestión de permisos y compartir cuatro cosillas

Notas finales

Para terminar ya me gustaría comentar un par de cosillas. Wixet funciona en cualquier sistema y a excepción de funciones avanzadas puede funcionar en cualquier máquina que cuente con php+mysql. Esas funciones avanzadas que hablo son las que sirven para mejorar el rendimiento principalmente. En 5 minutos se instala, y la mayor parte del tiempo es por las cosas que descarga durante la instalación.

Está basado en Symfony 2 y Doctrine 2, herramientas muy potentes y muy documentadas además de modernas (en constante mejora). Juntando estas herramientas a Wixet, no hace falta ser ningún gurú para crear tu propia red social personalizada. Por una parte se ofrece una gestión amigable de las páginas web, por otro lado de la persistencia de datos (base de datos) y por otro lado la seguridad y gestión.

Por supuesto es necesario algo de conocimientos, pero si alguna vez has estado tocando cosas en joomla, drupal y tus propias páginas PHP te moverás como pez en el agua. Tan pronto como se estabilice un poco la aplicación iré publicando la documentación, que ahora son borradores y diseños que en cualquier comento pueden cambiar.

Otra cosa, soy consciente de lo lento que va esto. La verdad es que trabajo en ello cuando me apetece (sin que suene mal). Igual durante una semana me siento con ganas y lo dedico un montón de tiempo pero durante la semana siguiente me apetece trabajar únicamente en mis robots y la siguiente vete tu a saber qué. Sé que no es una manera correcta de hacer las cosas, pero al hacerlas sólo cuando tengo ganas por lo menos hago chapuzas “para terminarlo ya” ni lo cojo tirria. Y ahora que lo pienso… en un futuro no muy lejano podría utilizar Wixet para compartir vídeos y fotos de mis robots en acción!

Un saludo!


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles





Latest Images