4

Here is the scenario:

  • Custom WCF Service deployed in SharePoint 2010
  • Site is using Claims Based authentication (FBA, NTLM)
  • .svc is deployed to ISAPI in the hive
  • Service is configured using custom service factory
  • Service is being called from the browser using AJAX
  • I am able to hit the service just fine; service is up and accepting requests

Here's the problem: SPContext.Current is always null. I know there are various techniques to "fake" an SPContext or obviously to create the SPSite and SPWeb manually, but should the SPContext.Current be null in custom WCF services when using Claims Based authentication? Or did I miss a step somewhere?

I've never run into this problem with classic mode authentication so I'm wondering if this is just something particular to WCF+SharePoint+Claims Based authentication and if there are possible workarounds.

Thanks for any insight!

-- Chuck

Improve this question
2
  • hey my question here is your SharePoint is claims based, how did u also make your WCF claims based and also when you execute any code in the WCF does it exceute under the claims/identity of the end-user or the app-pool account? Ideally I would love the code to be executed under the identity of the end user and not the app-pool.. can you confirm how you did it and what the case in your code? thanks
    – user5460
    Oct 31, 2011 at 3:25
  • @ketan see: informationworker.co.za/blogs/mirror/Lists/Posts/… except add this in the override of CreateServiceHost: SPIisWebServiceApplication.ConfigureServiceHost(host, SPServiceAuthenticationMode.Claims);
    – Charles Chen
    Feb 11, 2012 at 19:02

1 Answer 1

Reset to default
3

Arrrrrgh! Finally figured it out after messing with this for a good day.

I want to leave this here just in case anyone else runs into the same problem.

When I register the Javascript endpoint, I use the full URL of the service.

So if the root of my site is at: 

http://mydomain.com/sites/site1

I register it at: 

http://mydomain.com/sites/site1/_vti_bin/myservicedir/myservice.svc/js

This is all good and fine. When the request is made to to retrieve the Javascript stubs, I can see in fiddler that the request goes to: 

/sites/site1/_vti_bin/myservicedir/myservice.svc/js

However, I only just now noticed (finally, after staring at it for hours..........) that when I make a call to a service method, the URL is chopped off to:

/_vti_bin/myservicedir/myservice.svc/MethodName

Thus my SPContext is always null since there is no site context specified in the URL.

Looking at the Javascript stubs from SharePoint, I could see that the call to set_path() was using the chopped URL. Simple enough to fix by calling set_path() again with the correct path.

Improve this answer
2
  • Got a question on your solution? When you said callset_path() again with the correct path, do you mean updating jsdebug file on the fly or something or override that behavior in the javascript on the aspx page that is calling the WCF service?
    – Kevin Parker
    Oct 18, 2011 at 21:26
  • Do you have an example of how you are handling the set_path() fix? Thanx Rgds
    – SSP
    Jan 25, 2018 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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