My collegues and I are working on a web API that we are communicating with using knockoutjs. To avoid running into cross site scripting security built into browsers, we have the api located in a virtual directory in our website directory.
If we place a "stupid" html file in the directory, we can "talk" to the api with no problems. If we, on the other hand, try to reference the api in the virtual directory from umbraco it isnt found.
I looked around for various solutions, but most, if not all, are if you are using MVC3 which solutions doesnt really help.
Here is a bit of the javascript that tries to contact the API:
var API_URL = "/api/Subscriptions/";
function subscribe() { if($("#siteForm").valid()=== true){ alert("add subscriptiooncalled"); var mySubscription = ko.toJS(ViewModel); var json = JSON.stringify(mySubscription); alert(json); $.ajax({ url: API_URL, cache: false, type: 'POST', contentType: 'application/json', data: json, success: function (data) { alert("data is pushed"); }, error: function (error) { alert("ERROR STATUS: " + error.status + " STATUS TEXT: " + error.statusText); } }); }else{ } }
Doing this doesnt work either:
var root = location.protocol + "//" + location.host; var API_URL = root + "/api/Subscriptions/";
Note the alerts are for testing purposes. Anyway, the url in the code obviously dont work, and inserting the full url doesnt work either (http:// etc. etc).
If the api sits outside of Umbraco, then it may be when you make the request from inside of Umbraco, that Umbraco thinks you are trying to reach a node called 'subscriptions' underneath a node called 'api' in the root of the site.
There is a property called 'umbracoReservedUrls' in the web.config of Umbraco that allows you to exclude some Url's from being processed by Umbraco, you could try adding the url of your api in there, a bit like this:
Cool, glad you got it sorted, I've had similar issues with buttons not submitting in internet explorer, the most frustrating kind of issues to troubleshoot :-)
Referencing virtual directories in javascript.
My collegues and I are working on a web API that we are communicating with using knockoutjs. To avoid running into cross site scripting security built into browsers, we have the api located in a virtual directory in our website directory.
If we place a "stupid" html file in the directory, we can "talk" to the api with no problems. If we, on the other hand, try to reference the api in the virtual directory from umbraco it isnt found.
I looked around for various solutions, but most, if not all, are if you are using MVC3 which solutions doesnt really help.
Here is a bit of the javascript that tries to contact the API:
Doing this doesnt work either:
Note the alerts are for testing purposes. Anyway, the url in the code obviously dont work, and inserting the full url doesnt work either (http:// etc. etc).
Any suggestions? Using Umbraco 4.7.2 if it helps.
If the api sits outside of Umbraco, then it may be when you make the request from inside of Umbraco, that Umbraco thinks you are trying to reach a node called 'subscriptions' underneath a node called 'api' in the root of the site.
There is a property called 'umbracoReservedUrls' in the web.config of Umbraco that allows you to exclude some Url's from being processed by Umbraco, you could try adding the url of your api in there, a bit like this:
<add key="umbracoReservedUrls" value="~/config/splashes/booting.aspx,~/install/default.aspx,~/config/splashes/noNodes.aspx,~/VSEnterpriseHelper.axd,~/api/subscriptions" />
and see if that makes a difference ?
Umbraco should ignore the request, and allow the virtual folder to serve it instead.
Thank you for your time, but it ended up being an entirely different solution altogether.
I dont know if its several different solution culminating, or if its just this one, or dumb luck but we managed to get it to work.
It was the submit button. It was of the type "submit" and had to be of type "button", after that everything worked.
Oh god, how many hours we have wasted with this, haha.
I wont mark this as solution, as it will not help those who search for a topic of the same name (or a problem the topic name implies).
Cool, glad you got it sorted, I've had similar issues with buttons not submitting in internet explorer, the most frustrating kind of issues to troubleshoot :-)
is working on a reply...