Authentifizierung JSON API

bheisig

Hallo Niklas,

willkommen im i-doit Forum!

Einen Fehler habe ich nicht direkt entdecken können. Wahrscheinlich ist nur irgendwo ein kleiner Dreher drin. Mit dem User kommst du über die Web GUI ins System?

Ein generelles Problem kann ich ausschließen. Mit meiner Library konnte ich mich anmelden.

Request Header:


POST /src/jsonrpc.php HTTP/1.1
Host: demo.i-doit.com
User-Agent: i-doit-api-client-php 0.2-dev
Accept: */*
Accept-Encoding: application/json
Content-Type: application/json
X-RPC-Auth-Username: admin
X-RPC-Auth-Password: admin
Content-Length: 92

Request (JSON als PHP-Array):


array(4) {
  'version' =>
  string(3) "2.0"
  'method' =>
  string(11) "idoit.login"
  'params' =>
  array(2) {
    'apikey' =>
    string(6) "c1ia5q"
    'language' =>
    string(2) "en"
  }
  'id' =>
  int(1)
}

Response Header (Ausschnitt):


HTTP/1.1 200 OK
Date: Thu, 23 Mar 2017 16:53:17 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, X-RPC-Auth-Username, X-RPC-Auth-Password, X-RPC-Auth-Session
Access-Control-Expose-Headers: X-RPC-Auth-Session
X-RPC-Auth-Session: onndhb2pfd0t4rqvdhajkcnl40
Content-Length: 242
Content-Type: application/json

Response (JSON als PHP-Array):


array(8) {
  'result' =>
  bool(true)
  'userid' =>
  string(1) "9"
  'name' =>
  string(27) "i-doit Systemadministrator "
  'mail' =>
  string(22) "i-doit@acme-it.example"
  'username' =>
  string(5) "admin"
  'session-id' =>
  string(26) "onndhb2pfd0t4rqvdhajkcnl40"
  'client-id' =>
  string(1) "1"
  'client-name' =>
  string(17) "ACME IT Solutions"
}

Vielleicht hilft dir ein Blick hierauf weiter.

Viele Grüße
Benjamin

nklein

Hallo Benjamin,

schon einmal vielen Dank für deine Hilfe, leider haben mich deine Beispiele nicht weiter gebracht. Wie da du ja auch schon gesagt hast sieht grundsätzlich bei meinem Header/Body alles gut aus.

Ich habe mittlerweile noch ausprobiert ob es mit einem lokalen User funktioniert (Die User bis jetzt waren alle über LDAP), leider ohne Erfolg. Wenn ich die Authentifizierung allerdings serverseitig ausschalte kann ich die API problemlos verwenden.

Ich habe mein Anliegen jetzt an den Advanced Support weitergegeben. Mal sehen was die dazu sagen.

Gruß,

Niklas

ubruns

Hallo nklein!

So wie ich das aus den JSON-API Dokumentation lese, ist die Methode "idoit.login" nur für X-RPC Authentifizierung und nicht für "Basic" gedacht.

Wenn du mit Basic arbeitest, wirst du vermutlich die Daten mit jedem Request einfach mitsenden müssen.
Also die "Authorization: Basic dXNlcjpwYXNz" im Header bei jedem Aufruf von anderen Methoden mitsenden.

Muss mir das später noch mal selber genau anschauen.

Gruß
Ulli Bruns

franknagel

Hallo,

ich vermute, Sie betreiben i-doit mit FPM, dies wird allerdings offiziell nicht unterstützt. HTTP Basic Auth habe ich nie versucht im Zusammenhang mit der JSON-API, aber AUTH header werden aus Sicherheitsgründen oftmals nicht an das Skript durchgereicht. Hier kommt es auf die Konfiguration an. Es sollte allerdings auch gehen (vgl. src/classes/modules/api/controller/isys_api_controller.class.php "protected function apikey_login").

X-RPC-Auth-Username und X-RPC-Auth-Password wiederum überleben das name mangling von CGI nicht: X-RPC-Auth-Username -> X_RPC_AUTH_USERNAME woraus idoit dann X-Rpc-Auth-Username macht, welches durch den Unterschied in der Groß-Klein-Schreibung nicht erkannt wird. Das zweite Problem ließe sich jedoch recht einfach lösen, falls Synetics sich entschließen würde, dass zu unterstützen (vgl. src/classes/core/isys_core.class.php "public static function headers()").

Viele Grüße
Frank Nagel

bheisig

In der Tat unterstützen wir derzeit Apache 2.4 mit mod_php, aber nicht FPM. Wenn Niklas die Theorie zu FPM bestätigen kann, nehmen wir das gerne als Feature Request auf.

nklein

Hallo Herr Nagel,

Ich habe mal versucht nachzuprüfen ob bei uns PHP als Apache mod_php oder als CGI/FastCGI verwendet wird. Leider habe ich den Server nicht selbst aufgesetzt und weiß es daher nicht und habe auch keine Erfahrung mit PHP.

In der Liste installierter Pakete ist sowohl ein Paket für Apache als auch eines mit CGI aufgeführt.

libapache2-mod-php5/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
libphp-pclzip/stable,now 2.8.2-3 all [installed]
php-pclzip/stable,now 2.8.2-3 all [installed,automatic]
php5/stable,now 5.6.30+dfsg-0+deb8u1 all [installed]
php5-cgi/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed,automatic]
php5-cli/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-common/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed,automatic]
php5-curl/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-gd/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-json/stable,now 1.3.6-1 amd64 [installed,automatic]
php5-ldap/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-mcrypt/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-memcache/stable,now 3.0.8-5 amd64 [installed]
php5-mysqlnd/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-pgsql/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-readline/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed,automatic]
php5-snmp/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]
php5-xmlrpc/stable,now 5.6.30+dfsg-0+deb8u1 amd64 [installed]

Um zu sehen was jetzt tatsächlich vom Webserver verwendet wird habe ich mir eine php-File mit der phpinfo()-Funktion angelegt, dabei kommt folgendes heraus:

System	Linux lx-idoit-demo 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64
Build Date	Feb 8 2017 08:50:48
Server API	Apache 2.0 Handler
Virtual Directory Support	disabled
Configuration File (php.ini) Path	/etc/php5/apache2
Loaded Configuration File	/etc/php5/apache2/php.ini
Scan this dir for additional .ini files	/etc/php5/apache2/conf.d
Additional .ini files parsed	/etc/php5/apache2/conf.d/05-opcache.ini, /etc/php5/apache2/conf.d/10-mysqlnd.ini, /etc/php5/apache2/conf.d/10-pdo.ini, /etc/php5/apache2/conf.d/20-curl.ini, /etc/php5/apache2/conf.d/20-gd.ini, /etc/php5/apache2/conf.d/20-json.ini, /etc/php5/apache2/conf.d/20-ldap.ini, /etc/php5/apache2/conf.d/20-mcrypt.ini, /etc/php5/apache2/conf.d/20-memcache.ini, /etc/php5/apache2/conf.d/20-mysql.ini, /etc/php5/apache2/conf.d/20-mysqli.ini, /etc/php5/apache2/conf.d/20-pdo_mysql.ini, /etc/php5/apache2/conf.d/20-pdo_pgsql.ini, /etc/php5/apache2/conf.d/20-pgsql.ini, /etc/php5/apache2/conf.d/20-readline.ini, /etc/php5/apache2/conf.d/20-snmp.ini, /etc/php5/apache2/conf.d/20-xmlrpc.ini
PHP API	20131106
PHP Extension	20131226
Zend Extension	220131226
Zend Extension Build	API220131226,NTS
PHP Extension Build	API20131226,NTS
Debug Build	no
Thread Safety	disabled
Zend Signal Handling	disabled
Zend Memory Manager	enabled
Zend Multibyte Support	provided by mbstring
IPv6 Support	enabled
DTrace Support	enabled
Registered PHP Streams	https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports	tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters	zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, mcrypt.*, mdecrypt.*

Ich interpretiere das so, dass Apache die PHP-Anfragen bearbeitet also php_mod verwendet wird, korrekt?

franknagel

Die phpinfo zeigt für mich eindeutig, dass hier mod_php verwendet wird. Da Sie sowieso schon eine phpinfo anzeigen können, prüfen Sie doch mal was

curl -H 'X-RPC-Auth-Username: user' -H 'X-RPC-Auth-Password: pass' http://SERVER.NAME/phpinfo.php

ergibt. Sowohl unter "Apache Environment" (HTTP_X_RPC_AUTH_USERNAME) als auch "HTTP Headers Information" (ohne name mangling) sollten diese beiden Felder auftauchen.

nklein

Hallo,

ja das funktioniert auch soweit:


## Apache Environment

| Variable | Value |
| HTTPS  | on  |
| SSL_TLS_SNI  | idoit-demo.sv.nr  |
| HTTP_HOST  | idoit-demo.sv.nr  |
| CONTENT_TYPE  | application  |
| HTTP_X_RPC_AUTH_USERNAME  | api_user  |
| HTTP_X_RPC_AUTH_PASSWORD  | api_pass  |
| HTTP_COOKIE  | PHPSESSID=l7974pvji93s10n7qinmpvhsf0  |
| CONTENT_LENGTH  | 0  |
| PATH  | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  |
| SERVER_SIGNATURE  | <address>Apache/2.4.10 (Debian) Server at idoit-demo.sv.nr Port 443</address> |

franknagel

Was verhält sich denn

curl -H 'Content-Type: application/json' -H 'X-RPC-Auth-Username: USERNAME' -H 'X-RPC-Auth-Password: PASSWORD' http://SERVER.NAME/src/jsonrpc.php \
--data-ascii '{"version": "2.0","params": {"apikey": "APIKEY"}, "id": "1", "method": "idoit.login" }'

mit den VIER angepassten Werten? Das sollte eine Erfolgsmeldung samt session-id zurückliefern.

nklein

Ich denke ich habe das Problem gefunden. Ich habe bis jetzt für alle Requests den Advanced REST Client als Chrome-Erweiterung verwendet. Dieser scheint mit der Authentifizierung über X-RPC nicht zusammenzuarbeiten. Sobald ich den Befehl

curl -H 'Content-Type: application/json' -H 'X-RPC-Auth-Username: api_user' -H 'X-RPC-Auth-Password: api_pass' http://idoit-demo.sv.nr/idoit/src/jsonrpc.php \
--data-ascii '{"version": "2.0","params": {"apikey": "fqq6cqd50"}, "id": "1", "method": "idoit.login" }'

per curl aus einem Linux-Terminal verschicke bekomme ich eine Session-ID zurück…

Schon etwas komisch, da mein REST Client wunderbar mit der JSON-Schnittstelle reden kann, WENN die Authentifizierung serverseitig ausgeschaltet ist.

Ich bedanke mich hiermit bei allen Beteiligten für die Unterstützung!

Gruß,

Niklas Klein