You are not logged in.
Pages: 1
Bonjour,
Nous utilisons le plugin webservices ( rest.php ) pour automatiser la declaration DNS/Active Directory des machines GLPI.
Nous utilisons l'outil CURL pour communiquer avec le webservice glpi.
Tout fonctionne correctement du moment que l'on utilise la methode HTTP GET pour envoyer des parametres aux fonctions du webservice glpi.
Mais si l'on tente d'envoyer ces parametres via la methode HTTP POST, nous obtenons une page html nous indiquant que notre action n'est pas autorisée..
Ci dessous un extrait de la page html generee :
<script type='text/javascript' src='/plugins/datainjection/javascript/datainjection.js'></script>
<link rel='stylesheet' href='/plugins/datainjection/css/datainjection.css' type='text/css' media='screen'>
</head>
<body><div id='page'><div id='bloc'><div class='haut'></div><div class='center'><br><br><img src='/pics/warning.png' alt='warning'><br><br><span class='b'>The action you have requested is not allowed. Reload previous page before doing action again.</span></div><div class='bas'></div></div></div><div id='footer-login'><a href='http://glpi-project.org/' title='Powered By Indepnet'>GLPI version 0.83.7 Copyright (C) 2003-2012 INDEPNET Development Team.</a></div></body></html>
J'aurais donc voulu avoir confirmation que le plugin webservices etait bien en mesure de traiter des parametres qui seraient passer en "POST" avant de continuer dans mes tests
Je précise que je ne suis pas du tout specialiste GLPI.....
Vous remerciant d'avance pour votre aide.
Offline
La page concerne le plugin datainjection, pas webservice.
Oui webservice accepte les méthodes post (enfin pour rest, je sais pas vraiment)
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Bonjour,
La méthode POST est bien géré par le plugin webservice, cependant si tu souhaite qu'elle gère la méthode POST en REST il faut le lui indiquer :
Dans le fichier REST.PHP :
Remplacer :
//$method = (isset($_GET['method'])?$_GET['method']:'');
par :
$method = (isset($_GET['method'])?$_GET['method']:$_POST['method']);
Remplacer :
//$resp = $session->execute($method, $_GET, WEBSERVICE_PROTOCOL_REST);
par :
$resp = $session->execute($method, isset($_GET['method'])?$_GET:$_POST, WEBSERVICE_PROTOCOL_REST);
Ceci a peut être été ajouté dans la dernière version du plugin que je n'ai pas encore implémenté sur notre GLPI.
PS : pour gérer le traitement de la réponse en json j'ai également modifié cette ligne :
//header("Content-Type: text/html; charset=UTF-8");
header("Content-Type: application/json; charset=UTF-8");
Last edited by Lhermitain (2013-01-08 13:10:53)
Offline
Salut,
Merci pour vos réponses ..!
Il était temps que je me réveille, je pensais être abonné à ce sujet mais visiblement ce n'était pas le cas
Je vais faire les modifications et voir ce que cela donne.
Question plus générale :
Est ce que l'on peut compter sur la "pérennité" de ce module dans glpi notamment pour la partie REST ?
Offline
Je viens de faire les modifs dans le code de rest.php.
Malheureusement, des que j'essaye d'acceder a la page rest.php en passant des parametres en POST j'obtiens toujours le meme message d'erreur
Je dois faire une erreur quelque part mais je ne vois pas ou...
Ci dessous ma requete cliente suivi du log apache et de la reponse.
# Requete cliente
/usr/bin/curl -s -d "method=glpi.doLogin" -d "login_name=USERNAME" -d "login_password=XXXXXX" "http://glpi.xxxx.xx/plugins/webservices/rest.php"
# Log apache
IP.IP.IP.IP - - [30/Mar/2013:22:12:08 +0100] "POST /plugins/webservices/rest.php HTTP/1.1" 200 2990 "-" "curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5"
# Reponse
<head><title>GLPI - Accès refusé</title>
</head>
......
Cette reponse ne semble pas faite par le service rest car c'est une page web qui est retournée.....
J'obtiens en fait le meme resultat que celui présenté lors de mon premier post.
Remi semblait faire reference au plugin datainjection qui est effectivement present sur notre installation......
Last edited by lozair31 (2013-03-30 23:52:22)
Offline
Je viens d'identifier la cause de mon problème.
en fait cela n'a rien à voir avec le plugin data_injection.
C'est un problème de protection contre les attaques de type CSRF au niveau du plugin webservices.
dans le fichier setup.php du plugin j'ai la ligne suivante :
$PLUGIN_HOOKS['csrf_compliant']['webservices'] = true;
Cette configuration ne pose aucun problème tant que l'on passe les paramètres en GET.
Par contre elle bloque les accès si l'on tente de se connecter en passant les paramètres en POST.
Si l'on désactive cette fonctionnalité, les requetes en POST aboutissent.
Donc plusieurs questions se posent :
* Puis je désactiver cette protection uniquement sur certaines urls ou pour certains clients ?
* Quelqun peut il m'aiguiller sur le fonctionnement de cette protection au niveau de GLPI ou du module webservices
Merci d'avance pour votre aide
Offline
Il faudrait plutot essayer de définir dans la page rest.php (comme pour xmlrpc.php)
define('DO_NOT_CHECK_HTTP_REFERER', 1);
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Je viens de verifier, cette constante est deja declaree dans le fichier rest.php....
Offline
Effectivement...
Perso, j'utilise pas le REST...
Pour l'instant => utiliser GET ou passer en xmlrpc.
Je cherche une solution propre.
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Quand je desactive la protection au niveau du webservice est ce que cela la desactive globalement au niveau de GLPI ?
Offline
Pages: 1