Problems with Json API - "The JSON data sent to the api is invalid"

Discussion in 'General' started by wcdsantos, May 16, 2019.

  1. wcdsantos

    wcdsantos New Member

    Olá a todos, Eu tenho um problema / problema com a minha instalação do ISPConfig e gostaria de tentar resolvê-lo.

    {
    "code": "invalid_data",
    "message": "Os dados JSON enviados para a API são inválidos",
    "resposta": falso
    }

    chegou a baixar os scripts de exemplo e funcionou normal sem erro, onde percebi que antes dos dados serem enviados para o ISPConfig são transformados em json e so tudo acontece, mas como o aplicativo estou tentando integrar isso não tem essa conversão para json Eu gostaria de saber como posso corrigir esse problema.

    É anexado como eu estou integrando os dados e como o script de exemplo funciona.

    Eu gostaria de uma ajuda sobre como proceder para que os dados sejam validados corretamente no ISPConfig.
     

    Attached Files:

    Last edited: May 17, 2019
  2. Jesse Norell

    Jesse Norell Well-Known Member

    The REST api uses json, the SOAP api uses xml, you will have to use one or the other. I suppose you could implement a new api endpoint that uses some other format, if you must use that specific client and it can't be made to use those.
     
  3. wcdsantos

    wcdsantos New Member

    Jesse, good afternoon,
    the question is not about how they work, but whether there is any way to pass the data straight from the postman or any other system to ISPConfig so that it understands the data being passed as far as where I perceived this data error invalid is being caused because ISPConfig does not understand the past given via post and only understands when it is already converted into Json
     
  4. Jesse Norell

    Jesse Norell Well-Known Member

    Right, the error is caused because the data sent wasn't in JSON format, and the way to make ISPConfig understand the data is to convert it to JSON format. You are wanting to know if there is a way to send the data in another format? In a quick look at the code, calling json.php requires all data to be JSON format except the method named, derived from query string (see https://git.ispconfig.org/ispconfig...er/interface/lib/classes/json_handler.inc.php). It looks like you can call rest.php and any parameters sent to GET requests are read via the query string, but POST and PUT still need JSON (see https://git.ispconfig.org/ispconfig...er/interface/lib/classes/rest_handler.inc.php). And the only other option is SOAP. If you need something other than these, you would have to implement a new api endpoint.

    Offhand, what format is your client sending parameters in? (What Content-Type does it send?)
     
  5. wcdsantos

    wcdsantos New Member

    in general, it is a CRM that has an integrated module for communication with Apis in the Rest format and all data is sent in the same way as in the attached printout.

    Is there any way to convert json.php itself?
     
  6. wcdsantos

    wcdsantos New Member

    the whole doubt is è:
    json.php can convert this data alone in some way.

    and the rest.php file test returns:

    <!DOCTYPE html>
    <html lang="en">
    <head>
    <title>
    ERROR 400: INVALID REQUEST
    </title>
    </head>
    <body>
    <h1>400: INVALID REQUEST
    </h1>
    <p>The url you called is not a valid REST url.
    </p>
    </body>
    </html>
     
  7. Jesse Norell

    Jesse Norell Well-Known Member

    Yes, more or less, that's what I meant by implementing a new api endpoint. If you can't make the client talk to the server, make the server understand the client...

    The first thing you'd need to do is find out what format of data your client is sending, so you know how you'll be processing it on the server. Your screenshots don't indicate what that is. My guess is maybe application/x-www-form-urlencoded or multipart/form-data.

    You'll need to figure out how you do authentication; the current ISPConfig api setup uses session id's, so a separate call to login and obtain a session id for use in future calls which you make - your screenshot shows a button for authentication you might check, and also seems to show adding username and password parameters to the request itself (ie. so maybe "always send username/password" rather than obtaining a session id?). It would probably be easier and safer to reuse the existing authentication setup (if your client can be made to do that) than rolling your own, unless you're familiar with creating them, as it can be easy to inadvertently create an insecure setup.

    Keep in mind future updates of ISPConfig; it would likely be easier to copy json.php and json_handler.inc.php to new names, so change ISPConfigJSONHandler to some new class name and make your changes there, rather than keeping local copies of the core ISPConfig files or tracking changesets against future updates. And depending on what your client does/can do, it might be easier to start with ISPConfigRESTHandler than ISPConfigJSONHandler.

    If the change you need is something useful for others, consider contributing it back to the ISPConfig project (eg. create a merge request in gitlab with your changes). If you do modify an existing class to handle your client, it certainly seems more appropriate to have ISPConfigRESTHandler handle multiple formats of REST requests (based off the Content-Type header, I'd imagine), rather than making ISPConfigJSONHandler handle non-JSON data.

    Right, the interface in rest.php uses the query string to route function calls, see https://git.ispconfig.org/ispconfig...terface/lib/classes/rest_handler.inc.php#L135 and search the forums here for for rest.php examples (which all begin /remote/api/v1/{morestuff}).
     
    till likes this.

Share This Page