¿Debo ocultar los campos en las representaciones de recursos REST según la función de seguridad del usuario?

7

¿Cuál es la mejor práctica para exponer diferentes campos para un recurso según el rol del usuario / los privilegios de ACL en el sistema?

Digamos que tengo un punto final, groups/{:group_id} . Las reglas de mi negocio establecen lo siguiente:

  1. Los usuarios no autenticados pueden ver solo los campos: name y ID
  2. Los usuarios autenticados pueden ver: name , ID , managers y access_code campos
  3. Los administradores de grupo pueden ver name , ID , managers , access_code y members .

Respectivamente, los registros pueden parecer:

/* Non-Authenticated User */
{
    "id": "abe80d",
    "name": "Foobar Group"
}

/* Authenticated User */
{
    "id": "abe80d",
    "name": "Foobar Group",
    "access_code": "abc123",
    "managers": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
    }
}

/* Manager */
{
    "id": "abe80d",
    "name": "Foobar Group",
    "access_code": "abc123",
    "managers": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
    },
    "members": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
        "_href": "http://example.org/people/jvs239a",
        "_href": "http://example.org/people/nnd9323",
    }
}

¿Debería ser un único punto final / URI que muestre diferentes conjuntos de campos para diferentes niveles de autenticación, o debería de alguna manera dividirlos en tres URI diferentes?

Parece que diferentes URL para el mismo recurso son malas, pero ¿un cliente que no sabe exactamente qué campos se recuperarán también es malo? ¿Existe una mejor práctica en esta situación?

    
pregunta caseyamcl 20.11.2014 - 20:45

1 respuesta

4

Por lo general, una URI de un solo recurso porque desea separar las preocupaciones entre DONDE vive el recurso y la OMS lo accede.

En su caso, "QUIÉN" accede al recurso se determina en función de dos parámetros: ¿el usuario está autenticado? Si es así, ¿cuál es el nivel de autorización?

Para el nivel de autorización, puede implementarlo utilizando grupos, y puede agregar grupos a lo largo del tiempo, o cambiar el nivel de autorización de varios grupos a lo largo del tiempo. Eso no debería cambiar de dónde los datos necesitan ser recuperados por un cliente.

Un ejemplo práctico es que cuando un cliente (por ejemplo, una aplicación nativa en un dispositivo móvil) consume su API, autentificará al usuario y generará la vista en función de los datos que recupere. Si (en el lado del servidor), se agregan nuevos grupos o se cambia el nivel de autorización de un usuario, no debería tener ningún impacto en el código del cliente.

  

Parece que diferentes URL para el mismo recurso son malas, pero una   ¿El cliente no sabe exactamente qué campos se recuperarían también es malo?   ¿Existe una mejor práctica en esta situación?

Generalmente se espera que los clientes manejen estos casos. Si tenía URI por separado, todavía tiene el problema de que se está alcanzando un URI que requiere privilegios más altos que los que tiene el usuario, en cuyo caso, la solicitud solo tendrá que fallar. Y lo que es más importante, sin haberse realizado la autenticación, ¿cómo sabe un cliente a qué URL acceder?

Por otra parte, si se codificó al cliente para que espere datos de acuerdo con varios niveles de autorización, el código sería lo suficientemente genérico para manejar los casos futuros en los que se cambien los datos devueltos. Esto es importante porque generalmente no se debe asumir que un recurso permanece constante y no evoluciona con el tiempo.

Afortunadamente, hay muchas herramientas y técnicas disponibles tanto en XML como en JSON para manejar una cantidad arbitraria de datos devueltos desde el servidor, siempre que no se haya violado el contrato de esquema.

En el ejemplo que proporcionó, yo codificaría a mi cliente para que tenga el esquema para los cinco campos, pero espero que cualquier campo que no sea el nombre y la ID sea nulo. Si no es nulo, entréguelo al usuario, pero si lo es, no lo muestre o proporcione un mensaje apropiado. En el futuro, si decide permitir que los usuarios autenticados no vean el código de acceso o que los usuarios no autenticados vean a los administradores, el código del cliente no tendrá que cambiar.

    
respondido por el Omer Iqbal 21.11.2014 - 01:48

Lea otras preguntas en las etiquetas