Да, там что в первом, что во втором варианте клиент должен нажать на "считать", но во втором это будет вроде как на сайте и ничего дополнительно кроме службы ставить не придётся.

Если пока отложить пока вопрос о сигнализации вставки УСБ-токена и чтения из него, то пока меня интересует следующее:

1) эту службу надо внедрять в какой-то Виндовс-процесс или другую службу, которые стартуют автоматически, так?

2) если вы имеете ввиду браузерное СЛ-приложение, то как оно присоединится к службе, которая работает у клиента, да ещё, возможно, находящегося где-то у себя в локалке? Да и внебраузерное тоже.

И вообще, я всё ещё не понимаю, зачем нужна служба? Я могу данные из ДЛЛ получить непосредственно ВНЕБРАУЗЕРНЫМ СЛ-приложением (браузерным не могу). Т. е. служба будет делать то же, что и СЛ-приложение? Зачем тогда лишнее звено?

Изопропилuser73202) если вы имеете ввиду браузерное СЛ-приложение, то как оно присоединится к службе, которая работает у клиента, да ещё, возможно, находящегося где-то у себя в локалке? Да и внебраузерное тоже.
обратится по http при задании соответсвующей access-policy
Это как это? Вот работает где-то клиент в своей локалке, даже не на сервере своего придприятия, грузит себе мою страницу с СЛ-приложением. Откуда моё СЛ-приложение может узнать, где у клиента хостится служба и есть ли она вообще?

Вот если клиент обращается к моей службе - тут всё без вопросов. У службы есть постоянный адрес, она "смотрит" в Интернет. А как я узнаю, где у клиента служба - непонятно.


Но самое главное, я не понимаю, зачем она нужна. Если её использовать только для доступа к ДЛЛ, то этот доступ может и СЛ-приложение иметь напрямую, без всяких служб.

Изопропилuser7320Откуда моё СЛ-приложение может узнать, где у клиента хостится служба и есть ли она вообще?

сраный USB ключ где ?
там и сервис его обслуживающий.
Просетапить сервис придётся.
1. Куда лучше установить службу, чтобы она пускалась автоматом при старте компьютера клиента?

2. Как будет выглядеть адрес оконечной точки такой службы?

3. Т. е. вы полагаете, что если адрес оконечной точки будет известен (установка всегда в одно и то же место у всех клиентов), то тогда можно будет подписывать СЛ-приложение заранее на известный адрес сервиса (адрес оконечной точки)? И вне зависимости от клиентов и их конфигураций, никакая часть адреса этой оконечной точки не будет меняться при установке службы сервиса?

Всё же, решил СЛ "добивать". Уже смог нормально запустить браузерное СЛ-преложение с повышенным доверием, которое развернуло у клиента ДЛЛ и обратилось к ней через DllImport. Научился правильно создавать цепочки сертификатов и подписывать ими СЛ-приложения. Поставил сертификаты клиенту, добавил в реестре параметр - и всё заработало! Вобщем, всё, как в мануалах пишут.

Теперь осталось только XML-установщик создать, который настроит реестр и поставит сертификаты клиенту сам, обозвать этот установщик "скачать плагин" и задача решена. Главное, чтобы потом только хасповская ДЛЛка не подвела и нормально заработала. Ну и ещё решить вопрос с шифрованным каналом, по которому передавать данные на сайт через СЛ-плагин.

user7320Теперь осталось только XML-установщик создать, который настроит реестр и поставит сертификаты клиенту сам, обозвать этот установщик "скачать плагин" и задача решена.
Установщик создал с помощью WiX. В реестре лажу, сертификаты клиенту скидываю. Теперь HTTPS и собственно HASP...

А всё равно чисто через СЛ не получилось. Дотнетовская ДЛЛка, которая работает с сишной ДЛЛкой, содержит обёртки внешнего вызова функций из этой сишной ДЛЛки. Для СЛ пришлось бы писать то же самое, только мне самому. Я что-то не захотел, хотя дизассемблером посмотрел - слишком много кодить и я плохо понял, что там к чему.

Пришлось сделать так, как вначале советовали - через службу. Вот через неё получилось, и даже не пришлось СЛ давать повышенное доверие. Теперь у меня WCF-служба ссылается на .NET библиотеку, сама WCF-служба сидит в Windows-службе с автозапуском. А СЛ-приложение в браузере имеет ссылку на эту службу - с ключа всё читается. Данные, которые с ключа передаются, не секретные (только айди ключа) - т. е. HTTPS пока не требуется, а вот как защитить обращения службы к ДЛЛкам и ключу - надо подумать будет. Пока что у меня секретная информация, которая обазательно нужна для обращения к ключу, хранится в коде WCF-службы.

Подумаю, может, саму службу можно этим же Хаспом тоже зашифровать. Придётся ещё проверить вызовы функций - в зашифрованном ли там всё виде или нет передаётся.

Нет, работа с сертификатами и Виксом зря не пропала - я столько всего узнал за эти полтора месяца.