Can I specify requestHeaders in exportTo?

Answered

Hi,
I would like to use the exportTo functionality to send a CSV to a remote server. For security reasons I will need to specify custom request headers but I don’t see that functionality in the documentation. We have an end point that will accept multipart/form-data but looking at the export to documentation I only have the ability to specify a URL which will not be enough.
 
Thanks in advance for the assistance.

7 answers

Public
Tanya Gryshko Flexmonster December 27, 2018

Hi Christopher!
Unfortunately, the requestHeader property is not supported for exportTo API call.
However, we already planned to implement this feature in one of the nearest builds (ETA Jan 28).
We will keep you informed about the progress.
Thanks,
  Tanya

Public
Tanya Gryshko Flexmonster January 30, 2019

Hello, Christopher,
We are glad to inform you that this feature is already available. It should be specified in the following way:

var params = {
url : 'your server',
requestHeader: {
'Authorization':"znati 21521512454"
}
};
flexmonster.exportTo('pdf', params);

You are welcome to update the component.
Regards,
Tanya

Public
Christopher Phillips February 5, 2019

Thanks Tanya, I do need a little more clarity. I would like to see what the request itself looks like. I can see the headers in Chrome Dev Tools but the response I’m receiving from our end point is a “Bad Request” Is there anyway I can get more information?

Public
Dmytro Zvazhii Flexmonster February 5, 2019

Hello Christopher, 
Thank you for writing to us. Flexmonster creates the XMLHttpRequest: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest and sends a POST request of it. 
Firstly, there is a request without the export data. Such a request is necessary for checking if the sent request header is in the list of the servers ‘Access-Control-Allow-Headers’. If it is not then the request is denied and no data is sent to the server. If everything is correct then there is a one more POST request sent with data and request headers values. The last request is processed on the server and the data could be saved.
Usually, “bad request” error means that you do not have request headers to be configured on the server side. Please make sure, that the request headers you are trying to use are in the list of  ‘Access-Control-Allow-Headers’ on your server side.
Let us know if there is any other question.
Regards,
Dmytro

Public
Christopher Phillips February 5, 2019

Thank you both for the responses we got it working today! 
It turns out the issue was with the request payload. It was not made clear in the documentation but with the network tools we determined the following was being sent

Content-Disposition: form-data; name="filedata"; filename="youFileName.csv"

Our endpoint expected the name to be “file” not “filedata” we made the change on our end and it works!
 
Thank you again for adding this feature!

Public
Christopher Phillips February 8, 2019

Sorry to keep coming back to this tread but I do have another question which might be another feature request.
I would like to improve the error handling when exporting to a server. I’m using the callback but what’s being returned on Success and Error are very different.
 
With the callback I’m getting the following:

callback on success
{
data: "correct data here",
fileName: "correct filename here",
response: "{"code":200,"body":"expected body content here"}",
type: "csv"
}

callback on error
{
message: "Cannot Save File"
}

I would like to be able to properly inform the user of what has failed; 400, 401, 404, and so on. Simply returning a message with no context is not enough.
Our endpoint provides a standard response on error:

{
"code":400,
"body":["your export failed because of the follow"]
}

Please let me know if you need more clarification.
Thanks in advance for all the help!

Public
Dmytro Zvazhii Flexmonster February 11, 2019

Hello Christopher,
Thank you for your question.
Yes, you a right. There is some inconsistency between the success response and error response.
In such case, we will add an update which should allow passing the error response to the callback method, ETA Mar 11.
Also, our dev team will extend the default error message by adding the details about the error message.
We will keep you updated.
Regards,
Dmytro

Please login or Register to Submit Answer