Размещенное приложение поставщика SharePoint — SecurityTokenException: неверный эмитент или подпись

Я разработал размещенное приложение SharePoint, которое развернуто на сайте Office 365 SharePoint в целях тестирования. Все работает так, как ожидалось, до недавнего времени я хочу проверить его с другой учетной записью O365. Оба аккаунта имеют одинаковые права. Разница лишь в том, что второй создается месяцами позже.

Как вы уже догадались, второй пользователь не может использовать приложение. Я пробовал использовать разные браузеры и даже разные компьютеры. Я почти уверен, что на стороне клиента все в порядке, потому что он работает для одного пользователя. (Я очистил кеш браузера и временные файлы Interet для каждого случая.)

Проблема:

  • Один пользователь может просто щелкнуть приложение и запустить его.

  • Другой пользователь также может щелкнуть ссылку приложения на сайте SharePoint, но при этом получит пустую страницу.

Итак, я проверил свои журналы. Кажется, что после «appredirect» (которое запускается, когда вы нажимаете на свое приложение в SharePoint), связь между сервером sharepoint и моим веб-приложением начинается и сразу же останавливается из-за следующего исключения:

System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.IdentityModel.Tokens.SecurityTokenException: Invalid issuer or signature.
   at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.VerifySignature(String signingInput, String signature, String algorithm, SecurityToken signingToken)
   at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.ReadTokenCore(String token, Boolean isActorToken)

Я попытался перезапустить IIS и удалить временные файлы ASP.NET.

Есть ли у кого-нибудь идеи или объяснения, что здесь может пойти не так?

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

Спасибо!


person slmglr    schedule 10.09.2015    source источник


Ответы (1)


Мы спали на нем и на следующий день вопрос был решен. Мы до сих пор не знаем, в чем была проблема, и, вероятно, никогда не узнаем, что же произошло на самом деле.

Вот еще один подход из MSDN для решения этой проблемы, в отличие от нашего решения «переночевать», но я думаю, что это даст вам представление.

person slmglr    schedule 11.09.2015