SPContext.Current est censé être nul dans CUSTOM service WCF?

Question

Voici le scénario:

• Service personnalisé WCF déployé dans SharePoint 2010
• Site utilise l'authentification basée sur les revendications (FBA, NTLM)
• .svc est déployé à ISAPI dans la ruche
• Le service est configuré en utilisant l'usine de service personnalisé
• Le service est appelé à partir du navigateur en utilisant AJAX
• Je suis en mesure de frapper le service très bien; service et demandes d'accepter

Voici le problème: SPContext.Current est toujours null. Je sais qu'il existe différentes techniques de « faux » un SPContext ou évidemment pour créer le SPSite et SPWeb manuellement, mais devrait la SPContext.Current nulle dans les services WCF personnalisés lors de l'authentification basée sur les revendications ? Ou ai-je manqué quelque part une étape?

Je ne l'ai jamais rencontré ce problème avec l'authentification en mode classique, donc je me demande si cela est juste quelque chose de particulier à WCF + SharePoint + authentification basée sur les revendications et s'il y a des solutions de contournement possibles.

Merci pour toute idée!

- Chuck

Answer 1

Arrrrrgh! Enfin pensé à elle après déconner avec ça pour une bonne journée.

Je veux quitter ce ici au cas où quelqu'un d'autre se jette dans le même problème.

Quand j'enregistre le point final Javascript, j'utiliser l'URL complète du service.

Donc, si la racine de mon site est à:

http://mydomain.com/sites/site1

J'inscrire à l'adresse:

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

Ceci est tout bon et bien. Lorsque la demande est faite pour récupérer les talons Javascript, je peux voir dans Fiddler que la demande va à:

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

Cependant, je ne viens remarqué (enfin, après avoir regardé pendant des heures ..........) que quand je fais un appel à une méthode de service, l'URL est coupée à:

/_vti_bin/myservicedir/myservice.svc/MethodName

Ainsi mon SPContext est toujours null car il n'y a pas de contexte de site spécifié dans l'URL.

En regardant les talons Javascript de SharePoint, je pouvais voir que l'appel à set_path() utilisait l'URL hachée. Assez simple pour fixer en appelant set_path() à nouveau avec le bon chemin.