Is SPContext.Current Supposed to Be null in Custom WCF Service?

Question

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

Answer 1

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.