Hello,
I have a Ffastrans at home, in a farming environment, it works fine for years. Recently upgrade from 0.9 to 1.2.0, no issue.
I have done a new workflow :
- get an youtube URL from .txt
- populate variable "youtubelink" from .txt file
- get video with a youtube-dl personal
- transcode
- rename
This work fine.
I am trying to start this workflow from a webpage (webserver is on my synology) whith API.
When I try with postman or reqbin, I have no issue.
I send a post as application/json :
- id wf
- id start node
- input file (fake because i dont use it after)
- variable youtubelink.
But when I try with ajax, it does not work, because of CORS.
it seems CORS allow only text/plain with cross origin..
With ajax i can get list of all workflows for example (because is a "simple" request ?)
How can I configure CORS in FFastrans to resolve this issue ?
Best regards,
PD : I am from video, the website and this things i'am trying to learn as a hobby
FFastrans CORS api JSON
Re: FFastrans CORS api JSON
Hi rdecarlo,
welcome to the forum and thank you for using FFAStrans!
Yeah, ajax is a wild beast... you never know what it is going to do next
Well, what should i say: it is hard to guess the reason why they decided that content-type application/json must be forbidden for CORS requests but thats how it is. It's a thing that either the browsers or the jquery guys decide to change pretty frequently.
FFAStrans sends the "Access-Control-Allow-Headers: *" into every response. We will need to work into the latest changes in browsers regarding CORS limit in order to find out what headers they expect now.
Anyway, the content-type is not really of matter. The API server does not care about what you set there as you can post JSON only anyway. And on your side, you are guaranteed to receive JSON too.
When the response comes back as text into your success function, all you need to do is to do like "JSON.parse(res.responseText)" to make it valid json again.
Your request POST Body can be formatted from object to text by just doing JSON.stringify before you send it over using ajax.
You know, as we are normally working with "files" instead of URL's and Browsers do not have access to any full file paths, it is not a usual thing that programmers use javascript running in browsers to send jobs to ffastrans. E.g. the webinterface uses a proxy to forward all requests to ffastrans. It assumes that the user does not have direct network access to ffastrans.
One small tip, a nice integration with this can be done using the addtoany browser plugin, you can look in the forum for it.
Also, i typically use the "input file" variable to submit "single values" to the workflow instead of creating a special user_var for it. What you do is kind of cleaner but not neccessary for one value. You can access whatever value you put into "input file" in your workflow by using %s_source%
welcome to the forum and thank you for using FFAStrans!
Yeah, ajax is a wild beast... you never know what it is going to do next
Well, what should i say: it is hard to guess the reason why they decided that content-type application/json must be forbidden for CORS requests but thats how it is. It's a thing that either the browsers or the jquery guys decide to change pretty frequently.
FFAStrans sends the "Access-Control-Allow-Headers: *" into every response. We will need to work into the latest changes in browsers regarding CORS limit in order to find out what headers they expect now.
Anyway, the content-type is not really of matter. The API server does not care about what you set there as you can post JSON only anyway. And on your side, you are guaranteed to receive JSON too.
When the response comes back as text into your success function, all you need to do is to do like "JSON.parse(res.responseText)" to make it valid json again.
Your request POST Body can be formatted from object to text by just doing JSON.stringify before you send it over using ajax.
You know, as we are normally working with "files" instead of URL's and Browsers do not have access to any full file paths, it is not a usual thing that programmers use javascript running in browsers to send jobs to ffastrans. E.g. the webinterface uses a proxy to forward all requests to ffastrans. It assumes that the user does not have direct network access to ffastrans.
One small tip, a nice integration with this can be done using the addtoany browser plugin, you can look in the forum for it.
Also, i typically use the "input file" variable to submit "single values" to the workflow instead of creating a special user_var for it. What you do is kind of cleaner but not neccessary for one value. You can access whatever value you put into "input file" in your workflow by using %s_source%
emcodem, wrapping since 2009 you got the rhyme?