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

1) Если все таки портировать на другие платформы то Linux nestat показывает PID только у соединений от своего пользователя. Для других пользователей нужны права админа.
2) Как вы понимаете вам придется ограничить размер POST запросов и ответов на них. А что делать если нужно подписать больше? Или зашифровать большой файл в потоковом режиме?
3) Одним url в post для подписи тут явно не обойдется. Нужно ведь как то и ключ выбрать, и их перечислить, проверить подпись и ..... Все приведет к тому что придется делать API на уровне JS. Иначе пользоваться всем этим набором URL будет не сильно удобно.
4) Как только будет плодится количество url из 3 пункта вы скорее всего придете к тому что передавать надо не 1 параметр, а иногда и по 5. И что для этого скорее всего пользовать JSON удобнее чем просто POST параметры.
5) Если это будет сервис то как кидать окошко с предупреждением о доступе к ключам. Кто его будет кидать и в какое место )) (это в общем случае крайне не тривиальная задача)
6) А если захочется callback к пользователю?


После решения всех этих вопросов с большой вероятностью вы придете в аналог Native Message Host от Google. Только управлять запусками и сервисом вам нужно будет.

Надеюсь замечания будут полезными ))

Отредактировано пользователем 6 ноября 2015 г. 18:06:10(UTC)  | Причина: Не указана

Что бы приложение в ООM не ушло. Не зря же в их везде ограничивают )). Технически это все реализуемо. Я просто хотел обратить внимание что при разработке API обязательно надо на это закладываться. Как на потоковую передачу данных из страницы в ваш сервис так и обратно. Это добавит некоторое количество трудозатрат.


Типичная проблема показа окошка за браузером. Модальность окна относительно окна браузера. (Справедливости ради в плагинах та же беда)


Можно конечно )), но это уже немного больше чем просто http.


Chrome + Opera работает с Native Message. Есть подозрение что FF тоже к этому придет.


1) Да, требует. Но это не является проблемой. Пока за нашу практику ни кто не жаловался на это.
2) Полностью согласен.
3) Разработка не думаю что дешевле выйдет в итоге, поддержка скорее всего да.
4-5) FF скорее всего тоже к Native Message придет. Edge пока не знаем...



На текущий момент однозначного ответа у меня нет. Дьявол в деталях...
На момент когда мы делали плагин был только NPAPI и в целом он работал более менее. Сейчас другая ситуация. Очень вероятно что через годик все браузеры придут к Native Message Host и тогда с плагинами станет чуть проще. Но ваш опыт будет крайне интересным и познавательным.

Очень интересует данная тема.

Сейчас используем плагин, но в свете недавнего отказа Chrome от NPAPI,
грядущего отказа в Firefox и полного отсутствия плагинов в Edge очень хочется
качественное альтернативное решение. Очень устали от поддержки плагина.

Пытался сделать что-то подобное самостоятельно на C++, но не хватило знания языка.
Однако появился некоторый опыт, которым хочу поделится:

Большинство web-сервисов, использующих цифровую подпись работают по протоколу https.
Ни один браузер не позволит сделать кроссдоменный ajax запрос по протоколу http,
если сама вызывающая страница получена по https. Таким образом, локальный web сервер
должен работать по протоколу https. Это посложнее чем http. Но есть готовые способы.
На c++ получалось использовать библиотеку от mongoose. А на GO, например, https сервер
вообще реализуется в несколько строк.

Для работы https серверу требуется серверный сертификат, выданный
на доменное имя localhost центром сертификации, который есть в браузере
(системе). Иначе браузеры будут ругаться на недостоверное соединение. Можно
сделать самоподписанный CA сертификат, подписать им сертификат на localhost и
загрузить в хранилище доверенных корневых сертификатов. Как иначе, не придумал.
Но если это потребуется делать от конечного пользователя, то опять проблемы с поддержкой.
Поэтому нужно либо где-то взять настоящий сертификат на localhost, либо сделать чтобы
добавление корневого происходило прозрачно для пользователя, а здесь появляется простор
для злоупотреблений. Кроме того, если разные web-сервисы захотят воспользоваться одним
и тем же локальным сервером для подписи своих документов и будут давать пользователям
свои localhost и CA сертификаты, то между ними начнутся конфликты.

Если web-сервис использует Content-Security-Policy, что вообще-то нужно делать
обязательно если заботится о безопасности, то необходимо передавать на клиента
CSP правило вроде этого:

default-src 'self' https://localhost:8443;

то есть удаленный web-сервер должен заранее знать на каком порту у клиента
работает локальный сервер для подписи.

Если кто-то предложит готовое решение, готов побыть beta-тестером :)

Пока всё, что вспомнилось. Появятся еще мысли - напишу.

Спасибо!


В сообщениях выше мы прикладывали документ https://drive.google.com...-H7VXdCeFd5cFQ3ckE/view. В нем этот вопрос разобран в первом FAQ п.6. Вопрос сертификата решается прозрачно.
Сайт, открытый по HTTPS, может делать запросы к CS только по доверенному HTTPS-соединению. Как CS его обеспечивает?
При первом запуске он кладет свой сертификат SSL в список доверенных для текущего пользователя. На это не требуются права администратора.
Т.е. нужно купить сертификат SSL?
Нет, подойдет даже самоподписанный.


А зачем веб-сервисам (сайтам) назначать свои сертификаты localhost?



Этот момент мы упустили. Но, вроде бы, проблема небольшая и решение простое.
Для клиента, работающего на DEFAULT_PORT, ничего не поменяется. А клиент на CUSTOM_PORT должен сообщить серверу свой порт, затем сервер устанавливает ему cookie cs_port=CUSTOM_PORT, и при последующем обновлении страницы сервер уже будет знать, какой заголовок CSP ставить.


Примем во внимание этот момент.


Вопрос обратной связи уже поднимался. WebSocket - лишь одно из средств ее реализации. Но вообще их очень много, и работают даже в IE6 (пруфлинк). Библиотек предостаточно.

Отредактировано пользователем 13 ноября 2015 г. 11:48:23(UTC)  | Причина: Не указана

В "Доверенные корневые центры сертификации". Неважно, самоподписанный или нет. Если серийники разные, то конфликтов не будет. Пример.
Кстати, недавно узнал, что сертификат для локального сервера можно и купить, см. "суперфинт" в ридми примера. Это альтернатива установке своего корневого сертификата. Но возникает риск подмены домена, т.к. злоумышленник знает наш приватный ключ. Для работы с важными документами это неприемлемо. Поэтому только первый вариант, причем SSL выпускать не на localhost, а на 127.0.0.1 (или ::1), чтобы не было возможности подмены через /etc/hosts.

Что касается остальных вопросов/замечаний, пока не готовы обсуждать планы и детали реализации. Просто хотим выявить препятствия, которые не дают подходу с локальным сервером стать лучшей альтернативой браузерным плагинам, на примере КриптоПро SDK.

Отредактировано пользователем 16 ноября 2015 г. 12:15:49(UTC)  | Причина: Добавил