ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
995831 Топик полностью
fk0, легенда (16.04.2020 14:46, просмотров: 532) ответил Гyдвин на "Моя твоя не понимай" :) Я не вэб десигнер, и сервер у меня вообще на ДельфЯх, и во всем надо знать меру :) XML - это готовая выгрузка из базы 1С, которую надо прикрутить к телефонам и планшетам по внутренней сетке . Кстати, этот XML практически не отличается ни по структуре, ни по размеру от JSON. Плодить кучу JS файлов и пр. дребедени на каждый чих не комильфо. Посему выбираю только необходимые данные и динамически строю таблицу. Всего пара файликов - index.html и
Ну я ж вначале и рассказал как динамически строить таблицу. Только из шаблона, а на по байтикам вручную. Чтоб можно было поменять структуру и вид таблицы без изменения кода. Юзеров отличать, самое надёжное -- сертификатом. Клиенты охереют от сложности и ты тоже. Можно паролем. Но проблема пароля в том, что его можно подсмотреть и скопировать. Сам файл сертификата тоже. А я догадываюсь, что тебе размножение абонентов совершенно не нужно. У тебя на первом месте не 

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


Но ведь и MAC-адрес можно подсмотреть и скопировать. Грош-цена такой "защите". Да и статический адрес при определенных условиях тоже (см. ниже). Единственный разумный вариант -- привязка к ТВОИМ SIM-картам. SIM-карты не копируются (какой-то элемент системы должен обладать этим свойством обязательно). Но возникает вопрос, как проверить, что SIM-карта стоит именно та.


Можно отправкой SMS на номер (номер тоже твой, другую SIM-карту на этот же номер получить можно конечно, но сложно и незаконно). Отправкой SMS с этого номера -- нельзя (можно подделать). Нужно, чтоб веб-приложение умело читать SMS. В принципе можно сделать свою аппликацию с тем же chrome-браузером внутри и в javascript добавить функции для чтения SMS. Можно было раньше -- сейчас не знаю, гугль всё закручивает гайки и банит приложения с такими функциями.


Разные варианты чтения ICCID карты, IMEI и т.п., что может тоже можно сделать, очевидно не надёжны (твою аппликацию могут пересадить на виртуальную машину и всё будет как надо).


Если интернет доступен через эту же SIM-карту то и статические адреса не очень вариант. С одной стороны не нужно делать интерфейс для вычитывания SMS-сообщений. Но с другой стороны -- интернет с этого устройства могут через роутер и VPN раздать на другие устройства и все будут ходить как бы с одного адреса. Нужны дополнительные меры.


Можно предусмотреть и ручное копирование кода из SMS и с последующим разрешением работы на некий временной интервал для данного устройства, определяемого по присвоенной куке. Но cookie могут оперативно дуплицировать на другие устройства. Можно кроме cookie хранить IP-адрес, но см. выше вариант с роутером -- тоже недостаточно. Можно считывать некоторый fingerprint от браузера, но он может меняться в непредсказуемый момент (не надёжно, будут жалобы: повернул на бок планшет и фингерпинт другой), и наоборот, может не меняться от устройства к устройству (если всё идентично).


Совершать звонок из браузера было бы лучше. Проще. Все браузеры умеют открывать dialer для звонка. Но тут есть риск подмены номера. Потенциально, ты можешь установить call baring для всех номеров кроме одного заданного в записной книжке. Тогда позвонить или отправить SMS чтоб узнать свой номер абонент не сможет. И функцию исходящего звонка на твой сервер можно использовать для идентификации абонента (далее в DTMF кодом напикать случайное число полученное с сайта). Неудобно тоже, и номер узнать можно при большом желании, и тебе сервак с модемом нужен. И опять же можно всех дублированных абонентов посадить на один IP и ты их надёжно не отличишь, и звонить они будут через "прокси" в виде главного смартфона. Ничем не лучше варианта с кукой.


Я бы ограничился вариантом с авторизацией через СМС, кукой и таймаутом на срок жизни куки (на сервере разумеется, не в клиенте!) Плюс предпринял какие-то меры для защиты канала связи между браузером и сервером, чтоб воровство и вставка чужой куки были максимально затруднены. Но это значит не браузер, а своя аппликация: которая не использует никакие SSL-библиотеки с устройства и имеет всё в себе, а главное не доверяет никаким сертификатом на устройстве, а имеет свой вшитый. Потому, что иначе очень просто поставить готовый прокси который умеет воровать https-траффик путём установки своего сертификата. Наверное банковские приложения так и делают... Да сломать можно, но уже менее тривиально.


Но с другой стороны, клиенты вообще могут с другого конца зайти: весь траффик пустить через единственный терминал и единственный браузер (обладающий нужной кукой). Просто вместо твоего javascript там загрузится свой прокси. Который уже через свой сервак начнёт раздавать содержимое страничек. И ты при всём желании увидишь, что там один клиент и один браузер, а что им пользуются удалённо 10 разных клиентов -- не поймёшь. Этим и плохо любое браузерное решение -- его легко разобрать на составляющие и модифицировать.


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

[ZX]