Комментарии 39
Статья интересная, но оформление кода картинками — не очень хорошая затея. Лучше текстом)
Красиво подсвеченный код картинкой как раз неплохо (если цели копировать нет), но вот jpeg и криво вырезанные скриншоты это ужасно, создают представление о «профессионализме» компании… =/
Чему вы удивляетесь, это же ЕФС:
Epic
Fail
System
Код в jpeg картинках — это феерический звездец!
Epic
Fail
System
Код в jpeg картинках — это феерический звездец!
примеры кода можно посмотреть тут: периферийное API и работа с окнами в windows
Спасибо за комментарий, доработали
На localhost выставляется cервис, который доступен из JavaScript. От этого тоже решили отказаться, т.к. реализация более трудоемкая, требуется использовать веб-сервер либо писать свой.
И в итоге использовали веб-сервер.
Java отлично бежит из одной Jar с использованием Spring Boot или Vert.x.
Почему тогда не .Net?
К сожалению кроме как поднять локально сервер для работы со сканерами дактилоскопии не смогли ничего придумать… Хотели тонкий клиент вместо толстого, а получился утолщенный.
А можете чуть подробнее рассказать, как предполагается работать с устройствами, которыми сами инициируют события (а не отвечают на запрос JS-приложения в браузере)? Тот же сканер например.
И что будет, если пользователь откроет JS-приложение в нескольких вкладках браузера, а потом отсканирует штриход?
Там же веб сокеты, это не веб сервер. Так что ни с тем, ни с тем проблем не будет.
В этом случае будет во всех вкладках отклик.
И что будет, если пользователь откроет JS-приложение в нескольких вкладках браузера, а потом отсканирует штриход?
Я делаю так: страница загружает SharedWorker, который уже устанавливает WebSocket-соединение с драйвером. По событиям focus/blur на window, страница отправляет сообщения в воркер. Таким образом воркер знает, какой из страниц отправлять событие от драйвера. Плюс есть возможность реагировать на событие специальным образом, если ни одна из страниц не активна в данный момент.
Я бы electron заюзал, там уже внутри NodeJS.
Довольно очевидное решение, которое будет работать — почему бы и нет. Сам периодически такое пишу. Например, программа для прошивки MPOS терминалов написана именно на node.js — настройка в браузере, потом вызов локальной ноды, которая уже дёргает вендорское приложение или нативные мультиплатформенные модули. В плюсах — есть интерфейс, удобно работать, легко поддерживать, не надо размываться на ещё один стек. Минусов пока не обнаружено.
По вашему коду — непонятно, почему у вас в 2017 году древний javascript и callback hell как он есть.
Что-то вы намудрили. В начале статьи казалось, что вы хотите обойтись чисто браузером, безо всяких устанавливаемых приложений, но в итоге пришли к запуску node.js на каждом компьютере, да еще и под серверным аккаунтом.
На вашем месте я бы написал приложение со своим HTTP API, на любом языке, для которого есть библиотеки для работы с нужным оборудованием. Да, примерно как сейчас, но без серверного яваскрипта, все-таки не думаю, что он подходит для работы с кучей разного оборудования :)
На вашем месте я бы написал приложение со своим HTTP API, на любом языке, для которого есть библиотеки для работы с нужным оборудованием. Да, примерно как сейчас, но без серверного яваскрипта, все-таки не думаю, что он подходит для работы с кучей разного оборудования :)
не рассматривали JWS (java web start)? написать свой сервер — вот пример blindscanner.com/ru, вполне прикольная штучка. устанавливается просто.
прошу прщения — не правильная ссылка была выложена, Вот правильная unit6.ru/twain-web. (это не раклама, а пример удачного решения, на мой взгляд) Решаемая задача — аналогичная, использование web для подключения к железу. Причём устанавливаемый «сервер» доступен не только локальному компу, но и по сети.
Как взаимодействуют Браузер и сервер ясно, но было бы интересно про взаимодействие сервера и самой периферии. Какие разъемы, протоколы итп.
Стоило ли использовать socket.io в проекте? Мне кажется и без него вы могли реализовать WebSockets.
Конечно оно проще заюзать эту либу, но смысл? Ни в браузере, ни на сервере оно не нужно. Реализовать можно и без этой «библиотеки для чата».
И вообще: https://github.com/uNetworking/uWebSockets
Пишите на C++/С. Не нужна будет node с серверным аккаунтом.
Конечно оно проще заюзать эту либу, но смысл? Ни в браузере, ни на сервере оно не нужно. Реализовать можно и без этой «библиотеки для чата».
И вообще: https://github.com/uNetworking/uWebSockets
Пишите на C++/С. Не нужна будет node с серверным аккаунтом.
Вставлю свои пять копеек. Наверное самый главный аргумент против — это использование JS для работы со всем этим банковским зоопарком оборудования. Та же Java (на которой СберТех сейчас активно пишет, насколько я понимаю), или .NET, всяко лучше будут интегрироваться с этим железом. Получается что JS-ников у вас больше чем Java-истов:-) А так еще вот что хочется спросить — канал связи браузера с локальным WebSocket-сервером будет как-то защищаться (SSL)? Я голосую за Java и выкачивание актуальных модулей подключения к банковскому железу (JAR-ников) с внутреннего репозитория при каждой загрузке локальной среды исполнения перефирийного ПО (= включению компа).
А так еще вот что хочется спросить — канал связи браузера с локальным WebSocket-сервером будет как-то защищаться (SSL)?для этих целей существует wss/
Я голосую за Java и выкачивание актуальных модулей подключения к банковскому железу (JAR-ников) с внутреннего репозитория при каждой загрузке локальной среды исполнения перефирийного ПО (= включению компа).технология называется JWS.
НЛО прилетело и опубликовало эту надпись здесь
Тоже не пойму почему вместо HTTP врапера на с++ или GO к примеру вы выбрали ноду которую надо ставить на «более 100 тыс. операторов. „
А вы никогда не слышали про Electron?
WebUSB это только в хроме фича, или в стандарт / другие браузеры проберётся?
Оно доступно везде, или только для расширений?
Находила также, что есть что-то для работы с HID, но, вроде бы тоже только для хрома/расширений и только в экспериментальной версии.
Оно доступно везде, или только для расширений?
Находила также, что есть что-то для работы с HID, но, вроде бы тоже только для хрома/расширений и только в экспериментальной версии.
Я делал через JS <-> socket.io <-> Windows Service (C#) Тоже хорошо. Надо было соединять с Bluetooth, USB, Ethernet через спец драйвера
Мы лично для себя не смогли придумать что-то более адекватного чем orange pi с сервером на борту для общения с переферией
У меня давно периферия(сканеры штрихкода, весы, фискальные регистраторы) может через браузер работать используя для коммуникации websocket.
Который можно открыть как ws://localhost
И кроспплатформенный драйвер (на java или node ) читает локальные(а может и другого компа) rs-232 и «кричит в websocket»… и браузер обрабатывает.
Который можно открыть как ws://localhost
И кроспплатформенный драйвер (на java или node ) читает локальные(а может и другого компа) rs-232 и «кричит в websocket»… и браузер обрабатывает.
Был опыт разработки чего-то подобного. Возможно не «подводный камень» но все же вставлю свои 5 копеек, которые немного нам подпортили крови в свое время:
В данном решении необходимо помнить, что после того, как вы начнете использовать https для веб-страницы (зачастую сайт переводят на https в последний момент перед релизом), вы не сможете делать вызовы на ваш node.js сервер, работающий по http из-за Mixed Content.
В свою очередь, т.к. вы совершаете https вызов из браузера на localhost, вам необходимо чтобы этот localhost имел валидный SSL сертификат issued to «localhost», выданный trusted Certificate authority. Понятное дело, что никакой Certificate authority такой сертификат не выдаст.
И тут начинаются костыли и выбор из меньших зол:
1. Можно сгенерировать self-signed certificate для Certificate authority. Потом подписать этим сертификатом SSL сертификат на localhost. Теперь у вас есть SSL сертификат на localhost, но при этом вам придется устанавливать self-signed certificate c certificate authority в trusted root сертификаты вашей системы. Уверен корпоративные безопасники это по достоинству оценят. Вот тут есть информация про скандал с Dell, который установил свои сертификаты в trusted root и чем это закончилось.
2. Можно купить валидный сертификат на некоторый домен например example.com. Использовать его в node.js сервере, при этом в hosts файле переписать example.com на localhost. Что тоже ужасно.
Будет интересно от Вас услышать, как решите эту проблему у себя. Конечно при условии что вы будете использовать https для своего сайта.
В данном решении необходимо помнить, что после того, как вы начнете использовать https для веб-страницы (зачастую сайт переводят на https в последний момент перед релизом), вы не сможете делать вызовы на ваш node.js сервер, работающий по http из-за Mixed Content.
В свою очередь, т.к. вы совершаете https вызов из браузера на localhost, вам необходимо чтобы этот localhost имел валидный SSL сертификат issued to «localhost», выданный trusted Certificate authority. Понятное дело, что никакой Certificate authority такой сертификат не выдаст.
И тут начинаются костыли и выбор из меньших зол:
1. Можно сгенерировать self-signed certificate для Certificate authority. Потом подписать этим сертификатом SSL сертификат на localhost. Теперь у вас есть SSL сертификат на localhost, но при этом вам придется устанавливать self-signed certificate c certificate authority в trusted root сертификаты вашей системы. Уверен корпоративные безопасники это по достоинству оценят. Вот тут есть информация про скандал с Dell, который установил свои сертификаты в trusted root и чем это закончилось.
2. Можно купить валидный сертификат на некоторый домен например example.com. Использовать его в node.js сервере, при этом в hosts файле переписать example.com на localhost. Что тоже ужасно.
Будет интересно от Вас услышать, как решите эту проблему у себя. Конечно при условии что вы будете использовать https для своего сайта.
проблема существует, но если использовать websocket для связи с localhost, то всё сводится к установке самоподписанного сертификата для wss на локальный комп. Это несколько не камильфо, но для корпоративного использования можно. на всё остальное это не повлияет.
Решаю проблему модифицированным вторым способом. Есть сервер, который для localhost.example.com получает сертификат от LetsEncrypt и выкладывает его с ключом на HTTP-сервере. При запуске драйвер запрашивает новый сертификат и сохраняет его. В случае проблем с сервером, сохраненной копией можно будет пользоваться ещё 3 месяца. Остается также в hosts прописать localhost.example.com.
Предпосылка о переносимости изначально неверна, просто потому что драйвера непереносимы по определению. Соответственно, можно перестать заниматься придумыванием способа исполнения нативного кода через жепу из js и
1) под windows написать сервис на любом языке (напр. javase с оберткой), который локально под управлением svchost будет выполнять те же самые функции, но без извращений. Как бонус получаем централизованное обновление сервиса через ad (про что вы конечно же забыли). Под linux это на ура переносится на systemd, после того, естественно, когда все драйвера перепишутся. Про jws уже выше предлагали, это в принципе то же самое, только без управления.
или
2) запиливаются плагины под браузер (целевой в банке — ie11, а слова про линукс и хром — это, пардон, розовые мечты апологетов js) и все работает. Обновление плагинов осуществляется опять же централизованно через ad. У CryptoPro плагины, например, уже есть. Фраза «Это тоже нам не подходит, не является целевым, привязывает к браузеру и ограничивает универсальность.» является сомнительной демагогией.
1) под windows написать сервис на любом языке (напр. javase с оберткой), который локально под управлением svchost будет выполнять те же самые функции, но без извращений. Как бонус получаем централизованное обновление сервиса через ad (про что вы конечно же забыли). Под linux это на ура переносится на systemd, после того, естественно, когда все драйвера перепишутся. Про jws уже выше предлагали, это в принципе то же самое, только без управления.
или
2) запиливаются плагины под браузер (целевой в банке — ie11, а слова про линукс и хром — это, пардон, розовые мечты апологетов js) и все работает. Обновление плагинов осуществляется опять же централизованно через ad. У CryptoPro плагины, например, уже есть. Фраза «Это тоже нам не подходит, не является целевым, привязывает к браузеру и ограничивает универсальность.» является сомнительной демагогией.
1. Раскатка сейчас через microsoft sccm предполагается и подготовка пакета будет включать в себя драйвер и обвязку на JS (npm пакет модуля работы с периферией). Раскатка и поддержка самой JVM, не отличается от Node.JS. С Linux будет похожая история. Пока явных плюсов в написании модулей на Java не вижу.
2. От плагинов отказались намерено, о чем написали в начале статьи. Также были предложения писать свой браузер на основе готовых платформ…
2. От плагинов отказались намерено, о чем написали в начале статьи. Также были предложения писать свой браузер на основе готовых платформ…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с периферией из JavaScript: от теории к практике