XML data format for a query on Nextcloud OCS - node.js

The problem is about getting a direct download link to a Netcloud file.
Documentation :
To obtain a direct link:
POST /ocs/v2.php/apps/dav/api/v1/direct
With the fileId in the body (so fileId=42 for example).
I want to POST this URL with Nodes.js. What is the XML (I guess) format to set "fileId=42" in the body of my request ?
Everything I try returns me
"Invalid query, please check the syntax. API specifications are here:http://www.freedesktop.org/wiki/Specifications/open-collaboration-services." but noway there to get the format.
Samething with curl, no syntax is working.
In a more generic way what is the XML (I guess) format when querying the OCS API?

I answer my question:
At last I suceeded in making it work with curl, single/double quotes in Windows was the problem, fixed using "{" escape character.
This told me this was not about OCS data format itself as data is to be sent as it, ie "fieldId=42"
Switching from NojesJs/https lib to Axios fixed the problem. Probably some content-type header, however I tried 'application/x-www-form-urlencoded' which fits with the data to send.

Related

Search file in a folder from Onedrive in Azure logic app

I'm having an issue using the OneDrive for Business - List files in folder action.
I'm setting the path of the action to be a parameter received from a previous step via http request.
The value of the path is for example - /Clients/ER/EDI/ERGL/Source
When I hard code the path by selecting it in the OneDrive action, its value at runtime is
"datasets/default/folders/01RODCPVEAQQCC4IDDRBF3JHJW2GR43CXZ" and at design time it is set to
"path":
/datasets/default/folders/#{encodeURIComponent(encodeURIComponent('01RODCPVEAQQCC4IDDRBF3JHJW2GR43CXZ'))}
However, when I try and set the path via parameter, which at design time looks like this
"path":
/datasets/default/folders/#{encodeURIComponent(encodeURIComponent(triggerBody()?['Source']))}"
and is at run time - /datasets/default/folders/%252FClients%252FER%252FEDI%252FERGL%252FSource
it does not work. I'm obviously missing something here, with encoding the path parameter? Any suggestions?
Thanks,
Actually you get the true path, it's just in a encode format. You could find the example , the encodeUriComponent will return the URI-encoded string with escape characters.
So you could decode what you get with this expression:
decodeUriComponent(decodeUriComponent('%252FClients%252FER%252FEDI%252FERGL%252FSource'))
Then you will get the absolute path.
Hope this could help you, if you still have other questions, please let me know.

What base64 format to use for images in opendocument/odt <office:binary-data>, possibly base64ing with nodejs?

I'm attempting to save an image base64'ed with nodejs in a raw format to an ODT file for display in OpenOffice Writer.
The spec was not very clear, but I found an example. However, when I post the following base64'd image (that looks fine in html), I get a "Read-error" in OpenOffice and the image does not display.
The spec says that it uses rfc2045, but that spec is not very specific (unless I'm missing something).
Here's what I have:
<text:p text:style-name="qr-wrapper">
<draw:frame draw:name="img1" svg:width="150.0pt" svg:height="150.0pt">
<draw:image xlink:href="Pictures/0.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
<office:binary-data>
iVBORw0KGgoAAAANSUhEUgAAAJYAAACWCAIAAACzY+a1AAAABGdBTUEAA1teXP8meAAABjpJREFUeAHtm92OHTcMg7tF3/+VtwlaBB+8Q0Eee46HAHOlkSlaJmMLm5+v7+/vv/LLWYG/nZtP778ViIX2vw9iYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A+QWxgL7RWwP0BuYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A/wz40TfH193aiqSzp/87xrX+5FTubrbv9bZW0H38HM9vCLMw9pR9hXY2Lhq+3pNBcLOyq9GnNnFvJAN97uP+W7Zgl7UJwK08n/abgIyFPALpdUz5fgn8ncwp+amGVioZlhP9uNhT81McuszkIet/Omr8wMVct9Oxj2rOIOZ6dWYVSfCl/kcwsLcTyWYqGHT0WXsbAQx2Np5yx84sScSeTnLGFMPPOsZUw8851a4g/GuYUHxd+zdSzco+NBllh4UPw9W79xFnI+qZlETEcJ8rCWefJ0MMQfjHMLD4q/Z+tYuEfHgyyx8KD4e7beOQvVXJntVPHMzifi2QP5FYZ4YlhLDOMOhvjFOLdwUcDz5bHwvAeLHcTCRQHPl6/OQs6JXachZ2eudPDkUfhOXp2RtQrzUD638CFhP0cbCz+n9UM7xcKHhP0c7ReHxOe2LXfqzBXVNmsVptz8/8VdPJ29FjG5hYsCni+Phec9WOwgFi4KeL585yzk/ODJ1ExS+E4tMbti9jPbM/Ednl09/+LJLdwo5hmqWHhG9427xsKNYp6hujMLO299B8MTKzzzxKuYM0lhyEn8Sl7tpfKdfVXtkM8tHATx+4yFfp4NHcfCQRC/zzuzcPaUnDGztZwZs7Ud/Gxv7Ie1zKt9iSemU0v8EOcWDoL4fcZCP8+GjmPhIIjf551ZyDed77jKU5UOhnjGs7XEk4c9M088MSrPWhV3ajsYxf8rn1tYiOOxFAs9fCq6jIWFOB5LO/8dKeeHOj0xnRlADDlVnvzEq5g8rN2VV5yqnxv53MIbor2rJBa+y48b3cTCG6K9q2R1FnbeemJ4epXnHJrFs5b8zJOTcQezi3OWh30OcW7hIIjfZyz082zoOBYOgvh9rv4ZKU/M9515FavZQx6FUZyztcSTU+07iycna2f5yTPEuYWDIH6fsdDPs6HjWDgI4ve5cxZ2Ts95oPCdOUEMOVfyqp9OXvXAWmKYVz0TU8S5hYU4Hkux0MOnostYWIjjsbTzz0hnT8wZwFo1M4hRsaplfnbfWbzqjXlysjdimnFuYVOo98Ji4Xu9aXYWC5tCvRd25+dCnoZvOvMqnn33yd+p3YXfxUMdZjlZW8S5hYU4Hkux0MOnostYWIjjsXTn50L1pjPfOT3xnHOdPPlZyzxjxclahenk1V7MPxTnFj4k7OdoY+HntH5op1j4kLCfo139uZCdcmYwz3nDPGNVS4ziYa3CkKcTK07mydPZd6WWew1xbuEgiN9nLPTzbOg4Fg6C+H2uzsLO+04MZ8auvFJd8Ss886xlfjZW51U8xCvMkM8tHATx+4yFfp4NHcfCQRC/z9VZ+MSJOYc4G5jnvsQw34k7nMR09iKePbC2g2FtEecWFuJ4LMVCD5+KLmNhIY7H0urfF+46JecEOTkzOhjWqpg8jLkXY8VDDHmIZ554hWG+GecWNoV6LywWvtebZmexsCnUe2F3ZiFPw7ee+U7cmQ0Ko/LcV/U2W6vwip89MJ7Fs7aIcwsLcTyWYqGHT0WXsbAQx2NpdRbylGpmELNrHuziYW+duHNG8ig8+yeGefIUcW5hIY7HUiz08KnoMhYW4ngs7ZyFu06sZoPKc98OhngVr/Cw9gn+gTO3cBDE7zMW+nk2dBwLB0H8Pt84C6mimivMq5+liCEn8bMY1pKTPMSofKeWmCLOLSzE8ViKhR4+FV3GwkIcj6Wds5AzYOX0T/BwJqneuC/xzLNWYZgnnjExip/4Is4tLMTxWIqFHj4VXcbCQhyPpdVZyDf91InZQ2eurODVGRUn86p2MZ9buCjg+fJYeN6DxQ5i4aKA58vf+P8Lz6ti1UFuoZVdV83GwitVrHKx0Mquq2Zj4ZUqVrlYaGXXVbOx8EoVq1wstLLrqtlYeKWKVS4WWtl11WwsvFLFKhcLrey6ajYWXqlilYuFVnZdNRsLr1SxysVCK7uumo2FV6pY5f4FHaQ4Pt0WyyMAAAAASUVORK5CYII=
</office:binary-data>
</draw:image>
</draw:frame>
</text:p>
I could use a base64 conversion library, like for instance this nodejs one. What format is expected?
Well, folks the answer is as follows:
<text:p text:style-name="qr-wrapper">
<draw:frame draw:name="img1" svg:width="150.0pt" svg:height="150.0pt">
<draw:image xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
<office:binary-data>
iVBORw0KGgoAAAANSUhEUgAAAJYAAACWCAIAAACzY+a1AAAABGdBTUEAA1teXP8meAAABjpJREFUeAHtm92OHTcMg7tF3/+VtwlaBB+8Q0Eee46HAHOlkSlaJmMLm5+v7+/vv/LLWYG/nZtP778ViIX2vw9iYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A+QWxgL7RWwP0BuYSy0V8D+ALmFsdBeAfsD5BbGQnsF7A/wz40TfH193aiqSzp/87xrX+5FTubrbv9bZW0H38HM9vCLMw9pR9hXY2Lhq+3pNBcLOyq9GnNnFvJAN97uP+W7Zgl7UJwK08n/abgIyFPALpdUz5fgn8ncwp+amGVioZlhP9uNhT81McuszkIet/Omr8wMVct9Oxj2rOIOZ6dWYVSfCl/kcwsLcTyWYqGHT0WXsbAQx2Np5yx84sScSeTnLGFMPPOsZUw8851a4g/GuYUHxd+zdSzco+NBllh4UPw9W79xFnI+qZlETEcJ8rCWefJ0MMQfjHMLD4q/Z+tYuEfHgyyx8KD4e7beOQvVXJntVPHMzifi2QP5FYZ4YlhLDOMOhvjFOLdwUcDz5bHwvAeLHcTCRQHPl6/OQs6JXachZ2eudPDkUfhOXp2RtQrzUD638CFhP0cbCz+n9UM7xcKHhP0c7ReHxOe2LXfqzBXVNmsVptz8/8VdPJ29FjG5hYsCni+Phec9WOwgFi4KeL585yzk/ODJ1ExS+E4tMbti9jPbM/Ednl09/+LJLdwo5hmqWHhG9427xsKNYp6hujMLO299B8MTKzzzxKuYM0lhyEn8Sl7tpfKdfVXtkM8tHATx+4yFfp4NHcfCQRC/zzuzcPaUnDGztZwZs7Ud/Gxv7Ie1zKt9iSemU0v8EOcWDoL4fcZCP8+GjmPhIIjf551ZyDed77jKU5UOhnjGs7XEk4c9M088MSrPWhV3ajsYxf8rn1tYiOOxFAs9fCq6jIWFOB5LO/8dKeeHOj0xnRlADDlVnvzEq5g8rN2VV5yqnxv53MIbor2rJBa+y48b3cTCG6K9q2R1FnbeemJ4epXnHJrFs5b8zJOTcQezi3OWh30OcW7hIIjfZyz082zoOBYOgvh9rv4ZKU/M9515FavZQx6FUZyztcSTU+07iycna2f5yTPEuYWDIH6fsdDPs6HjWDgI4ve5cxZ2Ts95oPCdOUEMOVfyqp9OXvXAWmKYVz0TU8S5hYU4Hkux0MOnostYWIjjsbTzz0hnT8wZwFo1M4hRsaplfnbfWbzqjXlysjdimnFuYVOo98Ji4Xu9aXYWC5tCvRd25+dCnoZvOvMqnn33yd+p3YXfxUMdZjlZW8S5hYU4Hkux0MOnostYWIjjsXTn50L1pjPfOT3xnHOdPPlZyzxjxclahenk1V7MPxTnFj4k7OdoY+HntH5op1j4kLCfo139uZCdcmYwz3nDPGNVS4ziYa3CkKcTK07mydPZd6WWew1xbuEgiN9nLPTzbOg4Fg6C+H2uzsLO+04MZ8auvFJd8Ss886xlfjZW51U8xCvMkM8tHATx+4yFfp4NHcfCQRC/z9VZ+MSJOYc4G5jnvsQw34k7nMR09iKePbC2g2FtEecWFuJ4LMVCD5+KLmNhIY7H0urfF+46JecEOTkzOhjWqpg8jLkXY8VDDHmIZ554hWG+GecWNoV6LywWvtebZmexsCnUe2F3ZiFPw7ee+U7cmQ0Ko/LcV/U2W6vwip89MJ7Fs7aIcwsLcTyWYqGHT0WXsbAQx2NpdRbylGpmELNrHuziYW+duHNG8ig8+yeGefIUcW5hIY7HUiz08KnoMhYW4ngs7ZyFu06sZoPKc98OhngVr/Cw9gn+gTO3cBDE7zMW+nk2dBwLB0H8Pt84C6mimivMq5+liCEn8bMY1pKTPMSofKeWmCLOLSzE8ViKhR4+FV3GwkIcj6Wds5AzYOX0T/BwJqneuC/xzLNWYZgnnjExip/4Is4tLMTxWIqFHj4VXcbCQhyPpdVZyDf91InZQ2eurODVGRUn86p2MZ9buCjg+fJYeN6DxQ5i4aKA58vf+P8Lz6ti1UFuoZVdV83GwitVrHKx0Mquq2Zj4ZUqVrlYaGXXVbOx8EoVq1wstLLrqtlYeKWKVS4WWtl11WwsvFLFKhcLrey6ajYWXqlilYuFVnZdNRsLr1SxysVCK7uumo2FV6pY5f4FHaQ4Pt0WyyMAAAAASUVORK5CYII=
</office:binary-data>
</draw:image>
</draw:frame>
</text:p>
That is to say
the encoding cannot be prefixed with data:image/png;base64,
the <draw:image> element cannot have a xlink:href="Pictures/0.png" attributed. Even though the spec says it will be ignored if <office:binary-data> is present. Shrug.

How can send I the the byte array of a png through an AMF request using soapUI?

I'm currently trying to create a load test for my API using soapUI to send Adobe Message Format requests. I have a request that expects a byte[] data type, but I know next to nothing about Groovy or Java.
I've pieced together information from different threads and I'm trying to create a property expansion along the lines of "${byte[] contents = new File("C:/Users/jloiselle/Desktop/TestDragon.png").getBytes()}" which obviously does not work.
Can anyone help me out or at least point me in the right direction?
Thanks in Advance
You have the correct way of getting the bytes of the file;
new File("C:/Users/jloiselle/Desktop/TestDragon.png").bytes
How are you trying to send this array to the request?
After lookin at the soapUI tutorials again, I realized I was attempting to reference the property incorrectly.
The solution was as follows:
In the script window of my request I added:
def temp = new File("C:/Users/jloiselle/Desktop/TestDragon.png").bytes
parameters['contents'] = temp
Thanks for the verifying the syntax for geting the bytes of a file.

getXmlHolder and context.expand - What does the arguments description mean

I am trying to insert values into the Request and Capture the response from the soapui pro Testsuite/testcase/testStep, using groovy script, without creating any property or assertions using soapui pro wizard. Everything i am trying to do using groovy script file in Soapui pro. But after 11 days of my self learning process I am forced to ask the in the forum:
I went thru almost 100 sites talking about how to capture request/response value.
But none explains the following:
getXmlHolder ("DeliverStatus#Request")
what does "deliveryStatus" & "Request" means and what does it contains. Which part of xml file is it. What does it signify
context.expand
For all my attempts i have got Null exception.
But i have been able to successfull script using groovy in the "Script tab in the Response section". But unable to do in using testsuite Groovy Script.
Please help.. Thanking all in advance
Regards
Am
DeliverStatus is basically meaningless - it is the name of your test step.
Request means that you look at the XML request that will be sent by SoapUI.
You can replace Request with Response and get the result of the API call.
context.expend allows you to get the value of the request or the response as well as specific XPaths within them. I'm not familiar with the getXmlHolder method - but it looks like it gets an XML string as input (can be a fragment) and turns it into an object you can work with.
My recommendation - if you are not using it already, is to right click on the Groovy editing area and choose Get Data --> Test Suite --> Test Case --> Test Step --> Response --> and navigate to the path in the response to which you want to access.
This will set the value of that XML fragment into a string variable of your choosing.
Afterwards you can use the getXmlHolder to convert that string into an object.
I also recommend using the XmlSlurper for parsing an XML string into an object.

curl chunky parser error

"Received problem 3 in the chunky parser"
I can't for the life of me find what "problem 3" in curl refers to. I'm sure it has to do with the format of the chunk I'm sending from the app server to curl, but I can't figure out what is wrong with the chunk because I can't tell what "problem 3" is.
Any ideas?
The number you see there is CHUNKE_BAD_CHUNK from the CHUNKcode enum from lib/http_chunks.h from the libcurl source code. Given a quick look, it seems that it is mostly used when a CR or LF is missing from the chunked data.
I would recommend you investigate on the raw HTTP content stream to see what the problem is with the chunked format. RFC2616 section 3.6.1 documents it.
There is a similar post to yours. Again I'm not sure what your trying to sen across so I can not point out the problem but have look at this,
Why is this warning being shown: "Received problem 2 in the chunky parser"?
Hope this helps!
So, I ran into this with a CGI program.
Long story short, the CGI script was using Python, and printing the chunk header using the length of the string, then sending to the client using:
print data,
This appends a space, making the data one byte longer than the chunk header says it is. I fixed this by changing that line to:
stdout.write( data )
A hexdump of the data out of the CGI script was the tool that finally told me what was going on.

Resources