Является ли Spcontext.current быть нулевым в пользовательской службе WCF?

sharepoint.stackexchange https://sharepoint.stackexchange.com/questions/18430

Вопрос

Вот сценарий:

  • Custom WCF Service развернута в SharePoint 2010
  • Сайт использует аутентификацию на основе претензий (FBA, NTLM)
  • .svc развернута в ISAPI в улья
  • Служба настроена с использованием пользовательской службы
  • Сервис вызывает из браузера с помощью AJAX
  • Я могу просто нанести услугу просто отлично; Сервис встает и принимает запросы

Вот проблема: spcontext.current всегда нулевой. Я знаю, что существуют различные методы, чтобы «подделать» SPContext или, очевидно, создать SPSite и Spweb вручную, но должен spcontext.current будет нулевым в пользовательских услугах WCF При использовании аутентификации на основе претензий? Или я где -то пропустил шаг?

Я никогда не сталкивался с этой проблемой с аутентификацией Classic Mode, поэтому мне интересно, является ли это просто чем -то особенным для аутентификации WCF+SharePoint+на основе претензий, и есть ли возможные обходные пути.

Спасибо за проницательность!

- Чак

Это было полезно?

Решение

Аррррг! Наконец понял это после того, как возился с этим в течение хорошего дня.

Я хочу оставить это здесь на случай, если кто -то еще столкнется с той же проблемой.

Когда я регистрирую конечную точку JavaScript, я использую полный URL -адрес службы.

Так что, если корень моего сайта находится по адресу:

http://mydomain.com/sites/site1

Я регистрирую его по адресу:

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

Это все хорошо и хорошо. Когда запрос будет сделан для извлечения заглушек JavaScript, я вижу в Fiddler, что запрос идет:

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

Тем не менее, я только сейчас заметил (наконец, после того, как смотрел на это часами ..........) что, когда я звоню в метод обслуживания, URL -адрес отрублен:

/_vti_bin/myservicedir/myservice.svc/MethodName

Таким образом, мой SPContext является всегда null Поскольку в URL нет контекста сайта.

Глядя на заглушки JavaScript от SharePoint, я мог видеть, что призыв к set_path() использовал нарезанный URL. Достаточно просто, чтобы исправить, позвонив set_path() снова с правильным путем.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с sharepoint.stackexchange
scroll top