> APIs > API Platform 3: Seguridad para tus tesoros
Buy Access to Course
19.

Probar la autenticación por token

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

¿Qué tal una prueba como ésta... pero en la que iniciamos sesión con una clave API? Creemos un nuevo método: función pública testPostToCreateTreasureWithApiKey():

73 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 10
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 13 - 61
public function testPostToCreateTreasureWithApiKey(): void
{
// ... lines 64 - 70
}
}

Esto empezará más o menos igual que antes. Copiaré la parte superior de la prueba anterior, quitaré el actingAs()... y añadiré un dump() cerca de la parte inferior:

73 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 10
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 13 - 61
public function testPostToCreateTreasureWithApiKey(): void
{
$this->browser()
->post('/api/treasures', [
'json' => [],
])
->dump()
->assertStatus(422)
;
}
}

Así, como antes, estamos enviando datos no válidos y esperamos un código de estado 422.

Copia ese nombre de método, luego gira y ejecuta sólo esta prueba:

symfony php bin/phpunit --filter=testPostToCreateTreasureWithApiKey

Y... ninguna sorpresa: obtenemos un código de estado 401 porque no estamos autenticados.

Enviemos una cabecera Authorization, pero una no válida para empezar. Pasa una claveheaders configurada en una matriz con Authorization y luego la palabra Bearer y luego... foo.

Esto debería seguir fallando:

symfony php bin/phpunit --filter=testPostToCreateTreasureWithApiKey

Y... ¡lo hace! Pero con un mensaje de error diferente: invalid_token. ¡Qué bien!

Utilizar un código real

Para pasar un token real, tenemos que introducir un token real en la base de datos. Hazlo con $token = ApiTokenFactory::createOne():

82 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 63
public function testPostToCreateTreasureWithApiKey(): void
{
$token = ApiTokenFactory::createOne([
// ... line 67
]);
// ... lines 69 - 79
}
}

¿Necesitamos controlar algún campo de esto? En realidad sí. Abre DragonTreasure. Si nos desplazamos hacia arriba, la operación Post requiere ROLE_TREASURE_CREATE:

245 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 27
#[ApiResource(
// ... lines 29 - 30
operations: [
// ... lines 32 - 37
new Post(
security: 'is_granted("ROLE_TREASURE_CREATE")',
),
// ... lines 41 - 49
],
// ... lines 51 - 64
)]
// ... lines 66 - 83
class DragonTreasure
{
// ... lines 86 - 243
}

Cuando nos autenticamos a través del formulario de acceso, gracias a role_hierarchy, siempre tenemos eso. Pero cuando utilizamos una clave API, para obtener ese rol, el token necesita el ámbito correspondiente.

Para asegurarnos de que lo tenemos, en la prueba, establece la propiedad scopes enApiToken::SCOPE_TREASURE_CREATE:

82 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 4
use App\Entity\ApiToken;
// ... lines 6 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 63
public function testPostToCreateTreasureWithApiKey(): void
{
$token = ApiTokenFactory::createOne([
'scopes' => [ApiToken::SCOPE_TREASURE_CREATE]
]);
// ... lines 69 - 79
}
}

Ahora pasa esto a la cabecera: $token->getToken(). Ah... y déjame arreglarscopes: que debería ser una matriz:

82 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 63
public function testPostToCreateTreasureWithApiKey(): void
{
$token = ApiTokenFactory::createOne([
'scopes' => [ApiToken::SCOPE_TREASURE_CREATE]
]);
// ... line 69
$this->browser()
->post('/api/treasures', [
// ... line 72
'headers' => [
'Authorization' => 'Bearer '.$token->getToken()
]
])
// ... lines 77 - 78
;
}
}

¡Creo que ya estamos listos! Ejecuta la prueba:

symfony php bin/phpunit --filter=testPostToCreateTreasureWithApiKey

Y... ¡ya está! ¡Vemos los bonitos 422 errores de validación!

Probar un token con un alcance incorrecto

Hagamos una prueba para asegurarnos de que no tenemos acceso si a nuestro token le falta este ámbito. Copia todo el método de prueba... y pégalo a continuación. LlámalotestPostToCreateTreasureDeniedWithoutScope().

Esta vez, cambia scopes por otra cosa, como SCOPE_TREASURE_EDIT. A continuación, ahora esperamos un código de estado 403:

98 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 80
public function testPostToCreateTreasureDeniedWithoutScope(): void
{
$token = ApiTokenFactory::createOne([
'scopes' => [ApiToken::SCOPE_TREASURE_EDIT]
]);
$this->browser()
->post('/api/treasures', [
'json' => [],
'headers' => [
'Authorization' => 'Bearer '.$token->getToken()
]
])
->assertStatus(403)
;
}
}

Esta vez, vamos a ejecutar todas las pruebas:

symfony php bin/phpunit

Y... ¡todo verde! Un 422 y luego un 403. Ve a eliminar los volcados de ambos puntos.

Por cierto, si utilizas mucho los tokens de la API en tus pruebas, pasar la cabecera Authorizationpuede resultar molesto. Browser tiene una forma en la que podemos crear un objeto Browser personalizado con métodos personalizados. Por ejemplo, podrías añadir un método authWithToken(), pasar un array de ámbitos, y entonces crearía ese token y lo pondría en la cabecera

$this->browser()
    ->authWithToken([ApiToken::SCOPE_TREASURE_CREATE])
    // ...
;

Esto no funciona en absoluto ahora mismo, pero consulta la documentación de Browser para aprender cómo hacerlo.

Siguiente: en la API Platform 3.1, el comportamiento de la operación PUT está cambiando. Hablemos de cómo, y de lo que tenemos que hacer en nuestro código para prepararnos para ello.