ServiceStack Auth ProviderOAuthAccess

Question

В чем может быть причина, что в этом методе:

public override object Authenticate(IServiceBase authService, 
                                    IAuthSession session, Authenticate request)

Внутри session В одном случае ProviderOAuthAccess считается 1, когда я пробую его на своем экземпляре локального сервера аутентификации (http://localhost:5001), и когда я развертываю то же приложение на https://my - развернуто -instance.azurewebsites.net/ Я получил количество 0.

Обратите внимание, мое клиентское приложение запускается на локальном хосте через обычный (не ssl) порт. Не уверен, что это как-то связано или нет, но, как я уже сказал, с тем же поставщиком аутентификации, который я использую на localhost, я получаю правильное поведение, но когда я пытаюсь подключить свое приложение, чтобы использовать его из Azure, оно не работает должным образом .

Я могу получать обратные вызовы и т. Д., Но с этим сеансом что-то не так.

Answer 1

@ Shp, если файлы cookie пропали, ссылки на сеанс теряются. Потеря файлов cookie после перенаправления не является обычной практикой, они остаются для домена / пути, которому они были назначены, до истечения срока их действия (или удаляются, что достигается установкой даты истечения срока действия в прошлом). Временные файлы cookie (также называемые сеансовыми файлами cookie) сохраняются до тех пор, пока браузер не будет открыт, в то время как постоянные файлы cookie сохраняются после перезапусков браузера до истечения срока их действия (или они очищаются вручную).

Answer 2

Этот вопрос можно перефразировать так:

«Мой поставщик проверки подлинности не работает при запуске в Azure»

Метод Authenticate() является реализацией для провайдера аутентификации, который в случае успеха будет заполнен в AuthUserSession.ProviderOAuthAccess. Так что это не работает, но ваше сообщение не содержит никакой информации о том, почему оно не работает, что в конечном итоге зависит от используемой вами реализации провайдера аутентификации. Обычное поведение, которое большинство провайдеров аутентификации используют, чтобы указать, что это не удалось, - это перенаправить на фрагмент #f=XXXX, содержащий код ошибки, и в этом случае его неудачная попытка перенаправления OAuth обычно содержит #s=1.