Cross Domain

[Nic]

Hi,

I am trying to use the Kendo Upload control to post my file to a web server on a different domain.  Ultimately I intend to host my front end as pure html and my API which is built on ASP.Net on different servers.

For my API I have added the below headers which works fine for JSON requests however the Upload component is failing with the following error

XMLHttpRequest cannot load http://10.0.1.14/TransformWS/UploadFile.aspx. Origin http://localhost is not allowed by Access-Control-Allow-Origin.

I have tested the component on the same server as the upload script and I can confirm that it works perfectly.

HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
            
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers","Content-Type, Accept");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age","1728000");
 HttpContext.Current.Response.End();
}

Is it possible to do cross domain posts with Upload?

Kind regards,


Nic

[Johsua]

Kendoui folks,
No reply to this question? i am also working with the upload widget and need to do a cross domain/ origin call. how do we go about this.
Thanks

[Doug]

I, too, am running into this issue, and it's really even just me testing localhost.  I am working on my laptop doing the front-end (javascript/html only) and my receiving server is my SharePoint VM (which shows up as cross-domain).  Please provide an answer if possible.

[Doug]

Hmm...I realized that, in our production environment, I am going to be encountering this issue since the front end and the receiving end are going to be on two separate servers in disparate datacenters.  So I am going to start digging into what to do with this, but any help would definitely be appreciated since this is no longer just a localhost issue.

[T. Tsonev]

Hi,

The Upload can send files to another domain, but some caveats. This requires File API browser supports and a server that will accept CORS requests. The first requirement rules out IE, Opera and old versions of FF. Thus, the approach is not really viable.

The only reliable way is to use a server-side proxy.

I hope this helps.

All the best,
Tsvetomir Tsonev
the Telerik team

[Doug]

AH!  That makes it all make sense.  It was good news in my case since we have a very progressive environment to work in.  I got it to work and I'll detail how.

1.  The scenario is we have a custom page used to upload and archive documents in a SharePoint document library.

1.  We use a LOT of application pages in SharePoint as "standalone" internal applications.  Luckily, we have standardized on Chrome as our internal browser of choice.  We only deal with IE when dealing with customers.  Also, I have admin access to our SharePoint environments (including server-level logon capacity).  So it means that, for this scenario, I'm in the best possible situation.

2.  I created a SharePoint application page to be the server-side receiver for the uploader.  I receive the file, do the work, and then use JSON.NET to serialize a return object.  To allow the Kendo uploader to work, I flush the response and write my own:

HttpContext.Current.Response.Clear();

HttpContext.Current.Response.ContentType = "application/json";

HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Credentials", "true");

 

if (Request.UrlReferrer != null)

    HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Origin", Request.UrlReferrer.Scheme + "://" + Request.UrlReferrer.Authority);

 

HttpContext.Current.Response.AppendHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS");

HttpContext.Current.Response.Write(json);

HttpContext.Current.Response.End();

3.  The Kendo uploader gracefully falls out of the OPTIONS method and falls back to POST.  Since we use WebDAV, I'm not going to mess with the OPTIONS verb as that tends to conflict and do weird things to WebDAV if you're not careful (especially if you're in the _layouts folder).  So I just let it fall back to POST.  The only thing I lost doing it that was the built-in support for the progress bar.  This was negligible to me as the built-in spinner works just fine.

Also, I had to specify the url referrer in headers because, in SharePoint, you cannot keep allow credentials set to true in the header and have an "*" as the allow origin.  As this is a completely internal application and there would be multiple applications using this proxy, I just got the request referrer so that each request would add itself to the allow origin header.  Not the best security model, but, again, this is completely internal.

The same thing could also be accomplished by editing the web.config, but I hate messing with SharePoint's web.config if I don't need to.  It could be done like this (IIS7):

<?xml version="1.0" encoding="utf-8"?>

<configuration>

 <system.webServer>

   <httpProtocol>

     <customHeaders>

       <add name="Access-Control-Allow-Origin" value="*" />

     </customHeaders>

   </httpProtocol>

 </system.webServer>

</configuration>

In any case, Tsvetomir's response got us where we needed to be.  Granted, if we had to deal with IE, it would be less forgiving.  But, if you're in a good boat, this should work for you. 

Thanks!
Doug

[Daniël]

the anwer to this question is old, 2012, are there new ways to tackle this in the 2016 version of Kendo UI?

 

The reqwest library (https://github.com/ded/reqwest) enables me to do the requests to my web api (on a subdomain with CORS enabled for the main domain), so Kendo UI could in theory do the same

[Dimiter Madjarov]

Hello Daniël,

We covered the question in the support thread on the same topic.

Regards,
Dimiter Madjarov
Telerik