Если не менять алгоритм работы с NCALayer, то oAuth в данном случае можно использовать так:
— Используя oAuth можно авторизвать юзера и получить токен для работы с апи egov от его имени, при этом вход через текущий механизм произойдет только на стороне egov
— Используя полученный токен, дергаем апи egov'a, куда посылаем файл для подписи, в ответ получаем ссылку куда должен пойти юзер
— Редиректим юзера на эту ссылку (ссылка на домен егова ведет), он видит файл для подписи, использует эцп для подписи, после успеха/неаудачи возвращаем юзера на сайт
— Делаем опять апи вызов к егову, проверяем что файл подписан, забираем его себе
Из плюсов в этой схеме, все манипуляции с ЭЦП происходят на стороне egov, стороннему сайту нужно использовать только всем известный oAuth и реализовать три не сложных апи вызова к egov
Из минусов, проблема с NCALayer остается, но по крайней мере она будет существовать только в пределах самого egov, которому придется доверять
Information
Rating
Does not participate
Location
Семипалатинск, Восточно-Казахстанская обл., Казахстан
— Используя oAuth можно авторизвать юзера и получить токен для работы с апи egov от его имени, при этом вход через текущий механизм произойдет только на стороне egov
— Используя полученный токен, дергаем апи egov'a, куда посылаем файл для подписи, в ответ получаем ссылку куда должен пойти юзер
— Редиректим юзера на эту ссылку (ссылка на домен егова ведет), он видит файл для подписи, использует эцп для подписи, после успеха/неаудачи возвращаем юзера на сайт
— Делаем опять апи вызов к егову, проверяем что файл подписан, забираем его себе
Из плюсов в этой схеме, все манипуляции с ЭЦП происходят на стороне egov, стороннему сайту нужно использовать только всем известный oAuth и реализовать три не сложных апи вызова к egov
Из минусов, проблема с NCALayer остается, но по крайней мере она будет существовать только в пределах самого egov, которому придется доверять