Да, задачу цифровых подписей можно решить готовыми плагинами.
Мы поддерживаем КриптоПро CSP и ViPNet CSP, оба могут работать с КриптоПро ЭЦП Browser plug-in. Почему мы не стали его использовать:
Нам нужно подписывать pdf и docx, на c# нам это сделать намного дешевле и быстрее, чем на JavaScript (TypeScript). Там был код, который можно повторно использовать. Причем Word от 2007 до самого нового должен понимать наши подписи.
При необходимости в программе можно авторизоваться и подписывать документы не на той машине, на которой запущен браузер.
прослушивание запросов через HTTP.SYS требует настройки прав (которая, кстати, тут не показана);
Не требует, т.к. мы не слушаем никого снаружи, только сами себя. А если нужно слушать снаружи, Nancy умеет сама делать биндинг, повышение прав нужно один раз.
Слушаем запросы снаружи с помощью Nancy
hostConfigs.RewriteLocalhost = true;
два экземпляра программы от разных пользователей так запустить не получится, так что это решение получается несовместимым с терминальными серверами и с быстрым переключением пользователей;
Если делать программу службой Windows, то нужен только один экземпляр.
нужно придумывать уникальные имена для конечных точек — иначе сайт сможет по-ошибке начать работать с чужой программой аналогичного назначения;
Согласен.
порт 80 обычно у всех занят Скайпом.
Поэтому 80 порт, как и 443 не используется, там пул из десяти портов, разбросанных в диапазоне 10000-45000. Мы их по очереди прощупываем, вдруг какие-то из них тоже заняты. В примере используются порты 40850 для HTTPS и 40849 для HTTP.
По второй схеме будет работать, вот почему сделано по первому варианту:
1. Во внутренних сетях крупных компаний для левой программы часто получить доступ в интернет без танцев с бубном трудно. По крайней мере, там придётся привлекать к этому админов.
2. Но в браузерах обычно сеть настроена, не придётся делать эту работу дважды.
3. Уже специфично для меня — только 20% пользователей сервиса нужна эта функция, остальные работают с обычным веб-приложением.
Ключи мы не выпускаем, их пользователи делают сами, нам просто нужно ими документы подписывать.
С портом легко решается. Пример я не стал этим усложнять, но если мы не можем открыть порт, мы пробуем другой из списка — 10 штук (не подряд). А в браузере опрашиваем их по очереди.
Тут несколько причин.
1. Самая главная, как Sabubu уже написал, придётся распространять этот сертификат с закрытым ключом вместе с программой. Иначе она не сможет шифровать SSL-трафик с использованием этого сертификата, не имея закрытого ключа.
2. Срок действия платных сертификатов 1 год (видел, что можно сделать на 3 года максимум). Значит, программу нужно будет ежегодно обновлять — это просто лишняя работа.
3. За платные сертификаты нужно будет платить деньги.
4. Let's encrypt не подойдёт, там сертификаты валидны всего 3 месяца, придётся часто обновлять их.
5. Самоподписанному сертификату можем сделать срок службы хоть сто лет.
6. Неизвестно как поведут себя разные DNS-серверы, при попытке разрешить доменное имя на 127.0.0.1.
Спасибо, что уделили время на исследования. Я тоже проверил: Nancy.dll — 878 KB, Nancy.Hosting.Self.dll — 22 KB. У меня там, правда BouncyCastle.Crypto.dll на 2.5 MB.
Angular не на устройстве, на нём делаем приложение в интернете. А потом вдруг хотим, чтобы пользователи могли подписывать документы в нашем веб-приложении с помощью свей электронной подписи (а подпись по ГОСТ и на аппаратном носителе). Вот тут и возникает необходимость сделать локальную службу, которая слушает обращения от нашего сайта, и делает всю работу с железом и отдаёт подписанный документ (просто REST API, служба без пользовательского интерфейса).
А CORS, чтобы сайты с URL, отличным от нашего, не могли тоже воспользоваться нашей службой.
Речь в статье не об этом. Я рассказываю о локально запущенном сервере, к API которого хочу получить доступ с сайта app.example.com.
Т.е. из скрипта на странице app.example.com мне надо сделать запрос по адресу localhost
Кроме того,
Locally delivered files such as localhost and file:// paths are considered to have been delivered securely.
это по ссылке с MDN. В статье я пишу, что в IE 11 и Edge это не работает.
Owin сильно больше и сложнее, использую его на бекенде с приложениями на asp.net. Мне кажется для такой задачи его многовато. Но работать, конечно, будет.
Речь не о сложностях работы angular в браузере, а о том, что с работающего по HTTPS сайта нельзя сделать ajax-запрос на любой API, работающий по HTTP.
Спасибо за замечание, пожалуй уберу эту фразу, раз она смущает.
Конечно, это же эмулятор. Туда нужно ставить операционную систему, соответственно поддержка программ зависит от ОС в эмуляторе. А в этот эмулятор можно поставить практически любую ОС от DOS 1.0 до Windows XP. Эмулируются процессоры 8086, 8088, 286, 386SX, 386DX, 486, Pentium, Pentium MMX, Pentium PRO, IDT, Cyrix.
Для некрофилии лучше использовать эмуляцию, а не виртуализацию. Лучшее, что мне удалось найти — это 86Box (https://github.com/86Box/86Box). Может эмулировать много разных платформ и оборудования (десятки видеокарт для ISA, VLB, PCI, десяток звуковых карт, сеть, SCSI, IDE, Floppy, LPT, Serial, джойстики). В этой программе у меня работает Windows 3.1, 95, linux 2.2, причем работает звук, графика и сеть (!). Рекомедую. И не придётся отключать HyperV.
Не видел таких проектов на гитхабе, я знаю только один boilerplate с авторизацией, но там все сделано на клиенте, с другой стороны переделывать совсем немного.
Нужно, чтобы маршруты в angular router не совпадали с маршрутами в asp.net, а потом при переходе на страницу с url, которого angular не знает он сделает запрос на сервер и пользователь увидит нужную страницу. Я не встраиваю эти вьюхи в приложение в своём проекте, но это легко можно сделать с помощью iframe.
Создание одной командой уже само по себе неплохо. Для меня главное
преимущество — возможность использовать стандартную cookie-based авторизацию из asp.net core identity. Плюс возможность делать так:
Страницы авторизации и оплаты — это asp.net вьюхи — можно не переживать за кражу паролей и кредитных карт с помощью внедрения зловредного кода в node_modules (проверить все зависимости, которые тащит за собой ангуляр, а тем более сторонние модули просто невозможно). Плюс не авторизованный пользователь даже не получит кода нашего клиентского приложения.
Второй плюс — ноль самодельных костылей, которые надо потом поддерживать, все используемые функции — часть проекта ASP.NET Core и поддерживаются его командой.
В сущности, никакой миграции не нужно. Всего 3 шага:
1. Устанавливаем Microsoft.AspNetCore.SpaServices и Microsoft.AspNetCore.SpaServices.Extensions
2. Правим конфигурацию в Startup.cs
3. Создаём и настраиваем .angular-cli.json
Если до этого использовали webpack с хитрой конфигурацией, могут возникнуть трудности из-за того, что angular-cli на даёт такой гибкости. Да, можно извлечь weback.config из angular-cli, но это строго не рекомендуется разработчиками angular.
В моём проекте обновление того стоило. Содержать webpack.config.dev.js и webpack.config.prod.js больше не нужно — это экономит кучу времени.
Проблемы, решение которых вы описываете в статье, были характерны для старых шаблонов, созданных еще для .NET Core 1.0. Команда ASP.NET Core хорошо поработала, теперь client не прибит гвоздями к серверу, рекомендую использовать template от команды asp.net. Можно использовать angular-cli. А вся необходимая настройка состоит из пары строк:
context.UseSpaStaticFiles();
context.UseSpa(spa =>
{
if (env.IsDevelopment())
{
spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");
}
});
Нет, будем работать с обычным HTML DOM с помощью razor template engine, причем можно использовать параллельно любой javascript-код и с помощью оберток обращаться к нему из managed-кода. Там выше по ссылке в презентации всё это описано.
А WPF в браузере давно есть — полумёртвый Silverlight.
Мы поддерживаем КриптоПро CSP и ViPNet CSP, оба могут работать с КриптоПро ЭЦП Browser plug-in. Почему мы не стали его использовать:
Ну а сам подход можно применять не только для ЭЦП, а вообще для любой работы с железом, например со считывателями карт.
Не требует, т.к. мы не слушаем никого снаружи, только сами себя. А если нужно слушать снаружи, Nancy умеет сама делать биндинг, повышение прав нужно один раз.
Если делать программу службой Windows, то нужен только один экземпляр.
Согласен.
Поэтому 80 порт, как и 443 не используется, там пул из десяти портов, разбросанных в диапазоне 10000-45000. Мы их по очереди прощупываем, вдруг какие-то из них тоже заняты. В примере используются порты 40850 для HTTPS и 40849 для HTTP.
1. Во внутренних сетях крупных компаний для левой программы часто получить доступ в интернет без танцев с бубном трудно. По крайней мере, там придётся привлекать к этому админов.
2. Но в браузерах обычно сеть настроена, не придётся делать эту работу дважды.
3. Уже специфично для меня — только 20% пользователей сервиса нужна эта функция, остальные работают с обычным веб-приложением.
Ключи мы не выпускаем, их пользователи делают сами, нам просто нужно ими документы подписывать.
С портом легко решается. Пример я не стал этим усложнять, но если мы не можем открыть порт, мы пробуем другой из списка — 10 штук (не подряд). А в браузере опрашиваем их по очереди.
1. Самая главная, как Sabubu уже написал, придётся распространять этот сертификат с закрытым ключом вместе с программой. Иначе она не сможет шифровать SSL-трафик с использованием этого сертификата, не имея закрытого ключа.
2. Срок действия платных сертификатов 1 год (видел, что можно сделать на 3 года максимум). Значит, программу нужно будет ежегодно обновлять — это просто лишняя работа.
3. За платные сертификаты нужно будет платить деньги.
4. Let's encrypt не подойдёт, там сертификаты валидны всего 3 месяца, придётся часто обновлять их.
5. Самоподписанному сертификату можем сделать срок службы хоть сто лет.
6. Неизвестно как поведут себя разные DNS-серверы, при попытке разрешить доменное имя на 127.0.0.1.
Angular не на устройстве, на нём делаем приложение в интернете. А потом вдруг хотим, чтобы пользователи могли подписывать документы в нашем веб-приложении с помощью свей электронной подписи (а подпись по ГОСТ и на аппаратном носителе). Вот тут и возникает необходимость сделать локальную службу, которая слушает обращения от нашего сайта, и делает всю работу с железом и отдаёт подписанный документ (просто REST API, служба без пользовательского интерфейса).
А CORS, чтобы сайты с URL, отличным от нашего, не могли тоже воспользоваться нашей службой.
Т.е. из скрипта на странице app.example.com мне надо сделать запрос по адресу localhost
Кроме того,
это по ссылке с MDN. В статье я пишу, что в IE 11 и Edge это не работает.
Спасибо за замечание, пожалуй уберу эту фразу, раз она смущает.
2. Есть оптимизированные билды под разные платформы http://ci.86box.net/job/86Box-Optimized/
А вообще, PCem — тоже в активной разработке, надо следить.
Нужно, чтобы маршруты в angular router не совпадали с маршрутами в asp.net, а потом при переходе на страницу с url, которого angular не знает он сделает запрос на сервер и пользователь увидит нужную страницу. Я не встраиваю эти вьюхи в приложение в своём проекте, но это легко можно сделать с помощью iframe.
преимущество — возможность использовать стандартную cookie-based авторизацию из asp.net core identity. Плюс возможность делать так:
Страницы авторизации и оплаты — это asp.net вьюхи — можно не переживать за кражу паролей и кредитных карт с помощью внедрения зловредного кода в node_modules (проверить все зависимости, которые тащит за собой ангуляр, а тем более сторонние модули просто невозможно). Плюс не авторизованный пользователь даже не получит кода нашего клиентского приложения.
Второй плюс — ноль самодельных костылей, которые надо потом поддерживать, все используемые функции — часть проекта ASP.NET Core и поддерживаются его командой.
1. Устанавливаем Microsoft.AspNetCore.SpaServices и Microsoft.AspNetCore.SpaServices.Extensions
2. Правим конфигурацию в Startup.cs
3. Создаём и настраиваем .angular-cli.json
Всё описано в документации.
Если до этого использовали webpack с хитрой конфигурацией, могут возникнуть трудности из-за того, что angular-cli на даёт такой гибкости. Да, можно извлечь weback.config из angular-cli, но это строго не рекомендуется разработчиками angular.
В моём проекте обновление того стоило. Содержать webpack.config.dev.js и webpack.config.prod.js больше не нужно — это экономит кучу времени.
Правда есть недостатки, с помощью angular-cli невозможно (пока) убрать локали moment.js из бандла. А это лишние 300 Кб.
Вся магия в пакете Microsoft.AspNetCore.SpaServices.Extensions
А WPF в браузере давно есть —
полумёртвыйSilverlight.