Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
    
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 '11 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 '12 at 19:02
add comment

1 Answer

up vote 2 down vote accepted

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.

share|improve this answer
    
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? –  user5290 Oct 18 '11 at 21:26
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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