¿Se supone que SpContext.Current es nulo en el servicio WCF personalizado?

Question

Aquí está el escenario:

• Servicio WCF personalizado implementado en SharePoint 2010
• El sitio está utilizando autenticación basada en reclamos (FBA, NTLM)
• .SVC se implementa en ISAPI en la colmena
• El servicio está configurado utilizando la fábrica de servicios personalizados
• Se llama al servicio desde el navegador usando AJAX
• Puedo llegar bien al servicio; el servicio está arriba y aceptando solicitudes

Aquí está el problema: spContext.Current es siempre nulo. Sé que hay varias técnicas para "fingir" un spContext o obviamente para crear el SPSIT y SPWEB manualmente, pero debería el spContext.Current será nulo en servicios WCF personalizados Al usar la autenticación basada en reclamos? ¿O me perdí un paso en alguna parte?

Nunca me he encontrado con este problema con la autenticación del modo clásico, así que me pregunto si esto es algo particular para la autenticación basada en WCF+SharePoint+reclamos y si hay posibles soluciones.

¡Gracias por cualquier idea!

- Chuck

Answer 1

¡Arrrrrgh! Finalmente lo descubrí después de jugar con esto para un buen día.

Quiero dejar esto aquí en caso de que alguien más corra el mismo problema.

Cuando registro el punto final de JavaScript, utilizo la URL completa del servicio.

Entonces, si la raíz de mi sitio está en:

http://mydomain.com/sites/site1

Lo registro en:

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

Todo esto está bien y está bien. Cuando se hace la solicitud para recuperar los talones de JavaScript, puedo ver en Fiddler que la solicitud va:

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

Sin embargo, acabo de notar (finalmente, después de mirarlo durante horas ..........) que cuando hago una llamada a un método de servicio, la URL se corta a:

/_vti_bin/myservicedir/myservice.svc/MethodName

Así mi SPContext es siempre null Dado que no hay contexto del sitio especificado en la URL.

Mirando los talones de JavaScript de SharePoint, pude ver que la llamada a set_path() estaba usando la URL picada. Lo suficientemente simple para arreglar llamando set_path() de nuevo con la ruta correcta.