Authentifizierung JSON API



  • Hallo,

    ich versuche gerade mich über die JSON API zu authentifizieren. Folgende Dinge habe ich bereits ausprobiert:

    Basic HTTP Authentication:

    Header:

    Content-Type: application/json
    Authorization: Basic dXNlcjpwYXNz
    
    

    Body:

    {
        "jsonrpc": "2.0",
        "method": "idoit.login",
        "params": 
      	{
            "apikey": "2aeouee7qu"
        },
        "id": 1
    }
    

    Response:

    {
    "jsonrpc": "2.0",
    "error": {
    "code": -32604,
    "message": "Authentication error",
    "data": {
    "error": "Please specify a user by RPC Session header or HTTP Basic Authentication."
    }
    },
    "id": 1
    }
    

    X-RPC Authentifizierung:

    Hier habe ich einmal versucht den Username und das Password gleichzeitig in einem Header zu übertragen oder zuerst nur den Usernamen. Beides hat nicht funktioniert.

    Header:

    Content-Type: application/json
    X-RPC-Auth-Username: user
    X-RPC-Auth-Password: pass
    
    

    Body:

    {
        "jsonrpc": "2.0",
        "method": "idoit.login",
        "params": 
      	{
            "apikey": "2aeouee7qu"
        },
        "id": 1
    }
    

    Response:

    {
    "jsonrpc": "2.0",
    "error": {
    "code": -32604,
    "message": "Authentication error",
    "data": {
    "error": "Please specify a user by RPC Session header or HTTP Basic Authentication."
    }
    },
    "id": 1
    }
    

    Das kann doch nicht so schwer sein, schließlich habe ich nirgends sonst jemanden gefunden der danach gefragt hat 😉 Ich würde mich freuen, wenn mir jemand für beide Anmeldemethoden jeweils ein Beispiel für Header und Body liefern könnte und mir auch noch sagt ob method.login überhaupt bei einer Anmeldung in den Body gehört (Lasse ich den Body komplett weg gibt es auch eine Fehlermeldung, daher habe ich die Methode Login als mMn sinnvollste genommen).

    Gruß,

    Niklas


  • i-doIT Team

    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



  • 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



  • 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



  • 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


  • i-doIT Team

    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.



  • 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?



  • 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.



  • 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> |
    
    


  • 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.



  • 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


 


Datenschutz / Privacy Policy