Salut à tous,

je développe une application (jasba) en deux parties :

• un côté interface web (xhtml)
• un côté service web (xml-rpc)

J'ai donc créer deux modules : jasba_ui et jasba_api.

Pour la partie interface, je vais utiliser une authentification "classique" avec session etc... Pour la partie service web, il me faut une authentification HTTP. J'ai donc suivi les conseils donnés dans ce forum, j'ai créé un nouveau point d'entré (jasba_api.php) avec son propre fichier de configuration et (surtout) sa propre configuration d'authentification :

config/jasba_api/config.ini.php :

 [plugins]
 auth = jasba_api/auth.coord.ini.php

config/jasba_api/auth.coord.ini.php :

 on_error = 2
 on_error_action = "jasba_api~httpauth:login"

Et enfin, mon action jasba_api~httpauth:login :

    function login() {
         if( !isset($_SERVER['PHP_AUTH_USER']) || !isset($_SERVER['PHP_AUTH_PW'])
                 || !jAuth::login($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'], false))
         {
             sleep (intval($conf['on_error_sleep']));
             $output = $this->getResponse('xml');
             $output->setHttpStatus(401, 'Unauthorized');
             $output->addHttpHeader('WWW-Authenticate', 'Basic realm="Mon API"');
             $output->content = '<result>error</result>';
             return $output;
         }
 
         // On ne veut pas de session dans une authentification HTTP
         session_destroy();
 
         // Appelle l'action demandée à l'origine
         return /*jCallAction(jGetOrigAction())*/null;
     }

L'idée, c'est que si le navigateur ne s'authentifie pas (ou mal), on le force à le faire (HTTP 401). Si l'authentification est faite et valide, on appelle l'action demandée à l'origine. Et c'est là que le bas blesse. Comment :

1. Retrouver l'action d'origine (décoder l'URL, même si elle est significative ?)
2. Exécuter l'action et retourner son résultat ?

Je sais que le 2 est possible, j'ai vu du code un jour par hasard, mais je ne l'ai pas retrouvé maintenant que j'en ai besoin.

Question annexe, peut on désactiver la création d'une session (qui n'a pas de sens dans mon cas) plutôt que de faire un session_destroy() ?

Et enfin, plus généralement, ma façon de faire est elle correcte ? Y a t'il des pistes d'améliorations ?

Merci d'avance et bravo pour le travail fourni.

Salut,

Le code que tu as fait, serait à faire plutôt dans un plugin pour le coordinateur, plutôt qu'un contrôleur. Ainsi dans ton plugin, qui est appelé avant et après chaque action, tu vérifie avant les actions que le user est authentifié. Si il ne l'est pas, tu retourne un nom d'action qui fera le 401. Et sinon il laisse passer et l'action demandée s'exécutera tout naturellement. En gros, tu te refait le plugin auth. (d'ailleurs je trouve bizarre que ton action login ne soit executée qu'en cas de défaut d'authentification..)

Au passage, je serais intéressé par ce type de plugin, pour l'intégrer directement dans Jelix.

Pour ton histoire de session, je vois pas ce qui te gène. Pourquoi faudrait-il qu'elles soient désactivées ?

D'accord, je crois que je vois comment faire. Je vais y réfléchir et voir ce que je peux faire. Effectivement, maintenant que tu le dis, je me rend compte que mon action login est exécutée à chaque fois. Pas top comme façon de faire. Je vais y travailler.

Si j'obtiens quelque chose de correct, le code sera bien sûr à ta disposition.

Pour cette histoire de session, j'en conviens, c'est plus esthétique qu'autre chose. Dans mon esprit, un service web se doit d'être stateless. Or, une session vient un peu contre cette philosophie. Mais bon, il suffit que le client HTTP ne renvoie pas les infos de session pour que le résultat soit le même.

Ça permet d'économiser de la BP, de faciliter le développement , voir d'augmenter la sécurité etc..

Sur l'aspect BP c'est vrai, mais je pense qu'un couple login/password est plus ou moins équivalent à un identifiant de session en nombre d'octet. Sur la facilité de dev, je ne suis pas tout à fait d'accord. Mon plugin va vérifier que l'authentification est valide et c'est tout. Pas d'enregistrement en session, de vérification si la session est initialisé, ... Sur l'aspect sécurité, si c'est bien fait, d'accord. Mais il faut que ce soit propre pour éviter les vols de cookie & co (mais bon, je ne connais pas trop le domaine donc je ne vais pas m'attarder sur le sujet)

Petite précision pour le reste : c'est bien MA vision des choses, les autres font ce qu'ils veulent ;-)

Mon idée, c'est que chaque appel de méthode est auto-suffisant et indépendant des autres. Toutes les données non déductible doivent être passées en paramètres de la méthode.

Il y plusieurs avantages à cette façon de faire :

• pas d'erreur suite à des timeouts, le client peut faire une partie d'un job, partir 3 jours en forêt et finir ensuite
• pas de risque que le serveur s'emmelle parce que le client fait les choses dans le désordre (ou parce que le serveur s'est trompé en enregistrant le positionnement du client)
• dans des clusters, pas d'état à maintenir entre les noeuds, la réparition de charge devient facile
• on est pas dépend des choix de l'utilisateur (elle fait comment la lib HTTP si l'utilisateur désactive les cookies ?)