0

I am using the SPServices library to call a web service on a SharePoint site from the my Sites area.

The domains are set up as 'https://intranet.domain.com' and 'https://mysites.domain.com'. So I think there are some cross-domain issues, however, I am able to get data back when using IE 8, but not Firefox 5 or Chrome.

When I try Firefox and intercept the requests using Fiddler, the web service returns a 302 Found response for an error page that says "Request Format is Unrecognised."

I am using jQuery 1.4.2 and SPServices 0.6.2. Any other versions of these make the request not even call the web service in any browser.

Does anyone know how to move forward from here? I don't think it's a scripting error since it works in IE, but I'm open to suggestions.

|improve this question
  • 1
    Can you show what your code looks like? – Marc D Anderson Aug 5 '11 at 2:25
3

I see this is a bit of an old question, but it is unanswered so I'll offer a solution...

I have had issues getting the web service calls to work across domains. The issue for me has always been that the SPServices library should reside on the same domain that you're making the web service call to. Symptomatically, I've generally seen a fairly nondescript error in my debugging tools; it never seems to just give you a straight 403. You'd think that, by nature, a web service call is intended to go to a domain other than where you are, so I'm not sure if this is an issue within the way SharePoint processes scripts and requests, but I have seen this problem before in similar scenarios to yours.

Typically, I deploy jQuery and SPServices to the 14 hive using my branding solution. The "fix" that I came up with was to dynamically write the script source tags using an absolute URL to jQuery and SPServices on the domain I want to make the request to. If jQuery and SPServices are sitting in the 14 hive, then https://intranet.domain.com/_layouts/scripts/jQuery.js and https://mysites.domain.com/_layouts/scripts/jQuery.js are pointing to the same file. By dynamically writing the URL so that it's loading the JavaScript files from the domain that you'll ultimately be calling, I was able to mitigate the cross-domain issue.

If you're on intranet.domain.com and your script is loaded from intranet.domain.com and calling mysites.domain.com you'll have the issue. If you're on intranet.domain.com and your script is loaded from mysites.domain.com and calling mysites.domain.com it'll work just fine.

Hopefully that makes sense.

|improve this answer
  • Hi, Can you share an example of what you have put in your masterpage to rewrite the URL. – Greg Raymond Jun 18 '12 at 10:20
  • Interesting idea, but cannot get it to work. I reference my .js files on MySite with src="intra/_layouts...", but it doesn't help. – Jussi Palo Aug 27 '12 at 10:41
  • @JussiPalo It would have to be an absolute URL: http(s)://intranet/_layouts/script/path.js – webdes03 Aug 27 '12 at 12:39
  • Yes, it was absolute URL. Ended up using iframe. – Jussi Palo Aug 30 '12 at 13:05
2

I've never tried doing cross domain stuff with SPServices. You might want to bounce this question off the SPServices Codeplex discussion board too where it will be exposed to a higher focused group. The calls operate under the context of the current user, so ther emight be some authentication issues in the other browsers.

|improve this answer
1

For me jQuery.support.cors = true worked (Cross Origin Resource Sharing). The browser must support this feature. Hope this helps.

http://api.jquery.com/jQuery.support/

cors is equal to true if a browser can create an XMLHttpRequest object and if thatXMLHttpRequest object has a withCredentials property. To enable cross-domain requests in environments that do not support cors yet but do allow cross-domain XHRrequests (windows gadget, etc), set $.support.cors = true;.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.