Статус: Новичок
Группы: Участники
Зарегистрирован: 22.06.2020(UTC) Сообщений: 3 Откуда: Moldova
|
Добрый день, На тестовоом сервере https://stenddss.cryptopro.ru/STS/ реализовали интеграцию с сервисами подписи. Хотим реализовать и интеграцию ч сервисом управления пользователями, но столкнулись с трудностями. В POST запросе в документации нет упоминнании про авторизацию. В примерах авторизация тоже не мелькает(в примерах к сервисам подписи указана авторизация в заголовке: Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh ... 8CeXycwB6A) При взаимодействии с сервисом без авторизации получаем ошибку (401) Unauthorized Подскажите пожалуйста что мы не так делаем и в какую сторону копать?
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.06.2020(UTC) Сообщений: 3 Откуда: Moldova
|
Предполагаю что сертификат с ключём выданые для оператора должны использоватся для авторизации на канальном уровне при создании HTTPS подлючения, но при этом получаем ошибку: The request was aborted: Could not create SSL/TLS secure channel. Пробовали с CryptoPro CSP 4 и 5 версии.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 12.03.2019(UTC) Сообщений: 332 Откуда: Москва Сказал «Спасибо»: 5 раз Поблагодарили: 70 раз в 66 постах
|
Добрый день. Вопрос решается в рамках обращения №30847 на портале технической поддержки. |
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.06.2020(UTC) Сообщений: 3 Откуда: Moldova
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.06.2015(UTC) Сообщений: 28
Сказал(а) «Спасибо»: 7 раз
|
Доброго времени суток!
Вопрос по данной авторизации есть.
Во время получения первичного кода авторизации у кого-нибудь возникала такая ситуация? Авторизуюсь через порт 4430 Получаю статус 302 как положено, но ответом в заголовках немного другая информация предоставляется...
Content-Length: 0 Cache-Control: no-cache Date: Fri, 17 Jul 2020 08:36:40 GMT Expires: -1 Location: /STS/Errors/ProtocolError/?contextId=6d2cb78e0b8c60f64745dddf37596eee Set-Cookie: Dss_ErrorContext_6d2cb78e0b8c60f64745dddf37596eee=36bycODThXFkVDZYkAEDuLE0-CzEKlS7fm7P7wOFqxwuYweQtkJNiJs_rUzEETW_G_OuC21JiUZJrcZMwue-8Rf9I-yXXECr-VHqfbB4UKcnR7izNw8ZQGofG4Xbb9lPRMBllY_Ynl8UZAS0c8V-JyqNQzCx56TFB-5xCu8tM4xHQem4XnqV2iWmeOhfDf7Y; path=/STS; HttpOnly
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.06.2015(UTC) Сообщений: 28
Сказал(а) «Спасибо»: 7 раз
|
С получением первого кода разобрался.
Мучаюсь с получением операторского маркера доступа. Во время запроса маркера появляется сообщение: {"error":"unauthorized_client"} в инструкции описано что: 400 unauthorized_client OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
Все необходимые в рамках инструкции сценарии аутентификации настроены через командлет set-dssclient {AuthorizationCode, Implicit, ResourceOwner}
В чем может быть проблема?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 12.03.2019(UTC) Сообщений: 332 Откуда: Москва Сказал «Спасибо»: 5 раз Поблагодарили: 70 раз в 66 постах
|
Автор: faustoun С получением первого кода разобрался.
Мучаюсь с получением операторского маркера доступа. Во время запроса маркера появляется сообщение: {"error":"unauthorized_client"} в инструкции описано что: 400 unauthorized_client OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
Все необходимые в рамках инструкции сценарии аутентификации настроены через командлет set-dssclient {AuthorizationCode, Implicit, ResourceOwner}
В чем может быть проблема?
Добрый день. Возможно, в запросе указан некорректный redirect_uri. |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.06.2015(UTC) Сообщений: 28
Сказал(а) «Спасибо»: 7 раз
|
Цитата: Добрый день. Возможно, в запросе указан некорректный redirect_uri.
Дело оказалось в другом. В инструкции по получению маркера операторского доступа написано следующее: Цитата: Если в рамках сценария необходима аутентификация клиентского приложени и известен его секрет, запрос необходимо модифицировать.
Параметр client_id в теле запроса должен был заменен на заголовок Auhtorization HTTP-запроса, имеющий значение Basic Base64(client_id:client_secret).
На самом деле оказалось, то заголовок Auhtorization HTTP-запроса, имеющий значение Basic Base64(client_id:client_secret) нужно передавать в любом случае, даже если client_id в теле запроса, и при получении первичного кода, и при получении access_token - об этом не написано в инструкции Еще не понял следующее, после получения токена нужно ли еще получать делегирующий токен? Попытался создать нового пользователя после получения маркера, на что сервис мне выдал следующее сообщение: Цитата: System.Net.WebException: 'Базовое соединение закрыто: Непредвиденная ошибка при передаче.' IOException: Не удается прочитать данные из транспортного соединения: Удаленный хост принудительно разорвал существующее подключение.
Отредактировано пользователем 20 июля 2020 г. 13:41:10(UTC)
| Причина: исправил ошибки
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.06.2015(UTC) Сообщений: 28
Сказал(а) «Спасибо»: 7 раз
|
С последней ошибкой тоже разобрался. Теперь пользователи создаются. Спасибо за помощь!
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close