I have an ajax post request being sent to workflow, however my response to the browser is coming back as failed due to the cross domain protection of ajax, I have created a response file to send back to the browser with these headers however the browser is not accepting them.
The Workflow’s HTTP Server does not yet support CORS. The content of the response file is irrelevant: the permission has to be set in the HTTP headers, which you cannot set in the Workflow tool.
I’m afraid your only option would be to install a reverse-proxy in front of the HTTP server to handle the direct communications with client browsers, but doing so is beyond the scope of this forum.
I’m curious, though: how can there be a cross-domain request if everything is being served by the HTTP Server? Are you using it to serve AJAX responses for another web site?
I am stuggling to be honest in offering up a website from the workflow, it is not loading my external js files and css file, I am using the Resources folder set in HTTP 2 settings but still no joy!
I am not sure I understand: why wouldn’t you want that other website to be the one serving the JS and css files? Is it because it’s not under your control and you want to override some of its own js/css?
In any event, the HTTP server should never be considered to be a Web Server: it is there to accept input data and deliver on-demand content, not to provide replacement for a full-blown server.
Based on the fact I cant accept cross domain ajax requests and return a valid response (shame really) I have created the external site on worklfow, hence my comment on loading js files and css files, since posting however I have managed to get it to work.
Again not the best solution, as you mentioned.
I may just have workflow accept the ajax post for the data and some how verify the connection and if successful…
Because this might show up for searches in AJAX POST CORS queries (ahh I love the smell of geeky acronyms in the morning), I might as well add this little tidbit.
I know it’s not supposed to work but… welllllll it actually kind of does. I’ve successfully done requests from COTG to Workflow using AJAX even if it’s considered CORS, by kind of cheating just a tiny little bit (aka making CORS a little unsecure, but functional). But only for one specific purpose: Sending POST data and receiving JSON in return. Aka: JSONP.
So in one demo that I have (which is not publicly available as it’s not finished), I’m doing the AJAX request in the document this way:
As you can see, there’s that little jsonpCallback parameter with the value ‘iteminfo’… Well, my Workflow process returns a JSON type response that looks like this:
iteminfo({"success": true});
or
iteminfo({"success": false, "error": "Wrong API Key"});
This has the obvious limitation that it only works from jQuery’s .ajax() function and it must return JSON, but it is a functional CORS ajax request though.
Hum… yes, the JSONP method works but is extremely unsecured and must never be used with sensitive data, not to mention that you must absolutely trust the response to be what you expect it to be. In other words, it bypasses CORS in a way that justifies why CORS was implemented in the first place!
I would NEVER recommend using it other than for demo purposes. In other words, try it at your own risk.
The reverse proxy option is at least as simple to implement and much more secure.