Discussion :

[kstor4U]

Salut !

Je voudrais faire une application mobile capable de communiquer avec mon serveur.
Du coup, j'aimerais faire un API REST en PHP.

Après avoir lu quelques tutos, j'ai compris le principe mais il me reste deux questions sans réponse :
l'API n'est pas sensée avoir d'état... je comprends que l'API est supposée répondre toujours la même chose pour une même requête envoyée.
Comment je fais si je veux que le client n'ait accès qu'à certaines ressources selon ses identifiants ?
En gros, je vois deux solutions :

• garder une vaiable $_SESSION qui me permettra de savoir s'il est identifié.
• Garder coté client les ids et les renvoyer pour chaque requete au serveur. Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.

Est-ce que je n'ai rien compris ou est-ce qu'il y a une meilleure façon de procéder?

Le second point est plus pratique : Si j'ai bien compris, on appelle une ressource par son sous dossier. Du coup, est-ce qu'il faut recréer l'arborescence complète sur le serveur et mettre un fichier PHP dans chaque dossier associé à une ressource ou existe-t-il un moyen de renvoyer toutes les requêtes à un index à la racine de l'API ?
La seconde solution me paraitrait plus efficace parce qu'elle permettrait d'éviter de répéter plein de choses telles que la connexion à la base et toutes les fonctions courantes.

Je vous remercie d'avance pour vos réponses.

[mathieu]

Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.

Dans le cas où vous générer un identifiant de session, vous devrez aussi vérifier si cette identifiant est encore valide à chaque requête donc cela revient à peu prêt au même

Si j'ai bien compris, on appelle une ressource par son sous dossier.

le fait que l'URL ressemble à une suite de répertoire ne veut pas dire que les fichiers sur le serveur soient disposés de la même façon.
je connais des API REST qui redirige toutes les requêtes vers un fichier PHP unique qui analyse la requête pour choisir la réponse.
par exemple l'url exemple.com/gestion/clients/3 peut correspondre à l'espace de nom "Gestion", classe "Clients" et lecture du client avec l'identifiant 3.

[grunk]

Comment je fais si je veux que le client n'ait accès qu'à certaines ressources selon ses identifiants ?
En gros, je vois deux solutions :

• garder une vaiable $_SESSION qui me permettra de savoir s'il est identifié.
• Garder coté client les ids et les renvoyer pour chaque requete au serveur. Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.

La solution la plus courante est la suivante :
Une url permet de s'identifier. Par exemple /api/login.
On l'appel en fournissant login/mdp , en cas de succès de l'authentification l'API retourne un token qui identifie l'utilisateur. Voir par exemple JWT mais plein d'autre solution sont possible.
Le client fournit ensuite son token à chaque requête ce qui permet au serveur de vérifier à chaque requête si l'utilisateur est bien qui il dit être.

Une solution alternative plus simpliste est de mettre en place une authentification basic pour les url que tu veux protéger. Le client doit alors fournir login/mdp à chaque connexion. Je suis mois fan car tu expose régulièrement des données sensible. Ca impose évidemment du https.

je connais des API REST qui redirige toutes les requêtes vers un fichier PHP unique qui analyse la requête pour choisir la réponse.
par exemple l'url exemple.com/gestion/clients/3 peut correspondre à l'espace de nom "Gestion", classe "Clients" et lecture du client avec l'identifiant 3.

99% des API fonctionnent comme ça

[kstor4U]

Salut,

Tout d'abord merci pour vos réponses.
Désolé pour la réponse tardive, j'avais mal réglé mes notifications...

Techniquement, comment je fais pour rediriger tous les sous dossiers vers un seul fichier en PHP ? Est-ce que ça se fait en réglant un .htaccess ? Est-ce qu'il y a une meilleure solution ?

Par rapport à l'identification, pour le token, si je comprends bien une variable SESSION ferait l'affaire ?
Pour JWT, c'est drole, j'avais réfléchi à faire la même chose^^.

Le fond de ma question était de savoir si à chaque fois qu'un client voudra faire un UPDATE (par exemple), il me faudra en plus de l'update faire les requêtes pour savoir s'il a le droit de modifier tel champ de tel élément ?
Est-ce que ça ne serait pas plus léger de stocker ses droits dans une variable SESSION ? Mais du coup, ça ne serait pas très REST ?

Merci d'avance pour votre réponse. (les notifications sont activées ^^).

[grunk]

Très souvent une url /api/login n'est pas une succession de sous dossiers mais un chemin virtuel. Toutes les url pointe sur un index.php via htaccess et c'est cet index qui décide quel fichier utiliser en fonction de l'url.

Par rapport à l'identification, pour le token, si je comprends bien une variable SESSION ferait l'affaire ?

Pas de variable de session coté serveur puisque une api rest est stateless.
Le serveur recois le token du client et vérifie si il est valide. Si il l'est il a accès au contenu sinon ,on le bloque.

Le fond de ma question était de savoir si à chaque fois qu'un client voudra faire un UPDATE (par exemple), il me faudra en plus de l'update faire les requêtes pour savoir s'il a le droit de modifier tel champ de tel élément ?

Soit les droits sont dans le token. Et tu décide donc en fonction du contenu du token. Soit tu préfère ne pas le rendre publique et il faut alors trouver qui est l'utilisateur grace au token et vérifier ses droits en fonction de son identité à chaque requête.
C'est le principale inconvenient de rest , comme c'est stateless il faut répéter certaines actions.

[kstor4U]

Très souvent une url /api/login n'est pas une succession de sous dossiers mais un chemin virtuel. Toutes les url pointe sur un index.php via htaccess et c'est cet index qui décide quel fichier utiliser en fonction de l'url.
Pas de variable de session coté serveur puisque une api rest est stateless.
il faut alors trouver qui est l'utilisateur grace au token et vérifier ses droits en fonction de son identité à chaque requête.
C'est le principale inconvenient de rest , comme c'est stateless il faut répéter certaines actions.

Super, j'ai ma réponse.

Et ben ce ne sera pas REST !
Sinon, je vais passer mon temps à faire des jointures et bouffer des ressources pour rien.
Rien ne m'empêchera de faire du REST par la suite pour comparer.
Par contre, je vais utiliser le format REST (arborescence des ressources) pour que ce soit comprehensible.

Du coup, concrètement comment je renvoie toutes les requêtes à un index.php à la racine ? il y a mieux qu'un .htaccess ?

Merci encore

[grunk]

Comme je l'ai dit tu peux très bien inclure les droit d'utilisateurs dans le token. Ca implique juste d'invalider le token et donc forcer une réauthentification si les droits change.

Du coup, concrètement comment je renvoie toutes les requêtes à un index.php à la racine ?

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !favicon.ico$
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

il y a mieux qu'un .htaccess ?

non

[kstor4U]

Salut,

Merci pour tes réponses.
C'est exactement ce que je voulais savoir.

Pour ce qui est du Token, c'est intéressant, j'ai lu cet article : http://blog.inovia-conseil.fr/?p=236
Pour l'instant je galère avec Ionic, je dois apprendre une chose à la fois, je retournerai sur le token si j'ai le temps.

Encore merci !

[grunk]

Pour le token , il existe plein de librairies dans la plus part des langages. Voir le site officiel à ce sujet.

Un exemple en php dans une de mes API pour générer un token en utilisant https://github.com/firebase/php-jwt:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$token = array(
    "iss" => "dferBackend", //issuer
    "aud" => $cfg->url, // audience
    "iat" => time(), //Issued at
    "nbf" => time(), // Not valid before
    "jti" => base64_encode(random_bytes(32)), // json token id
    //"exp" => time()+60
    "data" => [
        'uid' => $userDatas['id'],
        'login' => $email,
        'acl' => serialize($acl)
    ]
);
 
$jwtKey = $cfg->jwtKey;
echo JWT::encode($token, $jwtKey,'HS256');

Tu peux voir que dans la partie "data" j'ai une entrée "acl" qui correspond aux droits de l'utilisateur en cours. Il faut juste être conscient que cette information peut être lue par tout personne ayant accès au token. Elle ne peux en revanche pas être modifiée sans rendre le token invalide.
Comme pour un cookie on ne place donc pas de données sensible comme un mot de passe dans un token.