Besoin d'aide ?

Laravel 8 et VueJS - Utiliser son API

Avatar de Seeryos
Seeryos

Bonjour à tous,

J'utilise Laravel 8 avec Passport pour le côté API et je viens de mettre en place VueJS dessus pour rendre mon frontoffice plus réactif.

Dans routes/api.php j'ai plusieurs routes qui utilisent le middleware client pour dialoguer avec une application mobile. Jusque là tout va bien. Maintenant, sur mes Vue Components j'utilise Axios pour récupérer des données. Le souci de la quasi totalité des ressources en ligne que j'ai pu trouver nous suggèrent de créer des routes WEB sans sécurité pour nos requêtes en GET. Le problème est qu'au final n'importe qui pourra appeler notre API et récupèrer librement et super simplement les données comme c'est le cas sur de nombreux sites web.

De mon côté, j'aimerais utiliser mes routes d'API qui utilisent le middleware client afin de :

  1. Ne pas coder 10 fois la même chose
  2. Sécuriser l'ensemble

Là encore, j'ai trouvé des infos comme quoi il faut passer le client secret et tout ce qui va avec directement dans le Vue Component au niveau d'axios. Mais encore une fois il suffira d'inspecter le code source pour trouver les accès. C'est pas super.

Sur la Doc de Laravel 8 j'ai trouvé ceci : https://laravel.com/docs/8.x/passport#consuming-your-api-with-javascript

Le problème est qu'en mettant en place la petite ligne dans Kernel.php et même en changeant le middleware de ma route par auth:api, j'ai un code de retour 401 Unauthorized.

Pouvez-vous m'aider ?

Voici mon code source :

app/Http/Kernel.php

protected $middlewareGroups = [
        'web' => [
            ...
            \Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,
        ],
        'api' => [
            'throttle:api',
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],
];

routes/api.php

Route::middleware('auth:api')->get('/explorer', [TaskController::class, 'index']);

Dans l'idéal, il faudrait que je change auth:api par client au niveau du middleware.

TaskComponent.vue

<template>

    <div class="tasks">
        <div v-for='task in tasks' :key='task.id' class="task text-center">
            <a :href="'/task/'+task.id">{{ task.label }}</a>
        </div>
    </div>

</template>

<script>
	export default {

		data(){
			return {
				tasks : {}
			}
		},

		created(){
			axios.get('/api/explorer')
				.then(response => {
					this.tasks = response.data;
				})
				.catch(error => console.log(error));
		},
	};
</script>

Merci beaucoup pour votre aide !

Posté il y a 3 mois
Avatar de Fred7877
Fred7877

Salut Seeryos, Tu a réussi à resoudre ton problème ?

Posté il y a 2 mois
Avatar de JérômeBorg
JérômeBorg

Salut tu peux regarder sur ce tuto pour la configuration de passport, je m'en suis servi avec react, mais c'est le meme principe https://www.positronx.io/laravel-rest-api-with-passport-authentication-tutorial/ A l'authentification, tu récupéres le jeton, que tu stockes en localestorage, et a chaque appel de l'api tu le passes en header je ne connais pas vu mais en react cela donne ceci const access_token = JSON.parse(localStorage.getItem('access_token')); apiClient.get('/api/emplacement', { headers: { 'Authorization': 'Bearer ' + access_token, 'Content-Type': 'application/json' } }) .then(response => {

Posté il y a 2 mois
Avatar de Seeryos
Seeryos

Hello @Fred7877 et @JérômeBorg.

Fred : J'ai contourné le problème en envoyant dans la view (au niveau du vuerouter) un client token pour exploiter mon API. Avant que la view s'affiche, je récupère ce token avec vuejs puis je le supprime de ma view. Après j'ai fait tout un micmac pour obfusquer les infos mais au final si tu étudies attentivement le code source de vuejs tu parviendras à retrouver l'info. C'est pas super propre ni super sécurisé mais c'est mieux que ma première solution

Jérôme : Merci pour ton message. Concernant l'authentification d'utilisateur je procède effectivement de la sorte. J'ai cependant quelques réserves sur le fait de stocker le token directement dans le localstorage du navigateur. ça te semble viable comme procédé ? Par contre mon problème initial est que justement sur mon site, en front, il n'y a pas de connexion d'utilisateur. C'est un site public et ouvert. C'est pourquoi je souhaiterais utiliser le middleware 'client'. Du coup, si je viens à stocker l'access_token dans le localstorage, je donne l'information à n'importe qui sur comment exploiter tranquillou l'ensemble de mon API =)

Je ne sais pas si je suis très clair !

Posté il y a 1 mois
Avatar de JérômeBorg
JérômeBorg

je ne suis pas expert en front de tous ce que jai lu, le token est souvant stocké en localstorage. cookie : mauvaise idee tu pourrais te creer une variable en js, mais tu serai obligé de te la passer de composant a composant

si ton api est ouverte au public sans authentification pourquoi utiliser un access_token ? il y a deux facons d'utiliser un token 1 lutilisateur se connecte et recoie en retour un token 2 un token est fourni a lutilisteur (par ex mail) dans les 2 cas le token est envoye en header dans toutes les requetes

Posté il y a 1 mois
Avatar de Rezrazi
Rezrazi

Quand un server-side API propose des resources à un client-side Frontend, il est impératif d'avoir un forme d'authentification si on veut restreindre l'accès à la consommation des terminaison de cet API, la solution la plus simple est avec un acces token, qui prend la forme d'un token JWT on va dire la majorité du temps.

Pour utiliser ce token, il faut le passer sur chaque requête HTTP en header pour authentifier et vérifier les autorisations, et il faut donc le sauvegarder quelque part sur la machine de l'utilisateur. Cette aproche peut sembler risquée côté sécurité, mais il est impératif de déléguer le stockage de ce token chez le client-side. Est ce que c'est risqué pour ton application ? Non, considère le token comme un login/password, c'est quelque chose que l'utilisateur a besoin de connaître pour s'authentifier, est ce que c'est risqué pour l'utilisateur, potentiellement, si sa machine est compromise, mais les navigateurs et appareils récents sont assez solides et savent bien gérer les formes de stockages navigateur ou bien mobile.

Maintenant pour le stockage, il existe deux formes (principales on va dire) en LocalStorage our Cookies, le localstorage est confié au navigateur, et c'est un stockage local, tu peux y déposer le token de l'utilisateur, et le récupérer au lancement de ton application ou bien à chaque requête, et il faudra l'envoyer sur chaque requête en un header Authorization Bearer. Les Cookies c'est quasi pareil, c'est stockage sur le navigateur de l'utilisateur, la différence ? c'est que les cookies d'un site web sont envoyés systématiquement à chaque requête, du coup tu n'auras pas à les spécifier dans tes headers dans les calls axios, personnellement je prèfére les cookies comme ça je n'ai plus à me soucier du header.

Ton cas d'utilisation "client" n'est pas très clair. Si ton application est ouverte au public, et tu veux restreindre l'accès derrière un middleware ? c'est contreproductif, et ça ne sert strictement à rien, avec un peu d'effort, n'importe qui pourrait pister tes requêtes depuis l'application mobile et reproduire les mêmes requêtes à volonté. Si ton application dispose d'un système de login, passeport sera adéquat pour gérer ça, sinon, ne t'embêtes pas avec et cherches plutôt à orienter tes efforts vers d'autres parties plus importantes.

Posté il y a 1 mois
Avatar de Seeryos
Seeryos

Merci beaucoup pour ta réponse @Rezrazi ! Effectivement, il arrive toujours un moment où l'utilisateur parviendra à récupérer mon token client (attention je ne parle de login d'utilisateur) ! Du coup, je n'ai pas de moyen d'empêcher un utilisateur d'appeller mon API en dehors de mon site s'il connait ce token ?

Il me semblait que AlloCine avait réussi pourtant car trop de personnes exploitaient sans problème leur API !

Merci en tout cas !

Vous ne pouvez pas répondre à ce sujet.