Вход | Регистрация
    1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

Обмен данными с мобильным приложением. Нужен совет. Советы :)

Обмен данными с мобильным приложением. Нужен совет. Советы :)
Я
   fisher
 
19.05.21 - 10:27
1. Как лучше, XDTO в json или структуры в json и почему?
2. Как обеспечить гарантированное сжатие пакетов?
3. Как решить вопрос безопасности? Токены какие-нить прикрутить? Стоит ли с JWT заморочиться?
В ветку призывается Garykom и все желающие :)
 
 Партнерская программа EFSOL Oblako
   Kassern
 
1 - 19.05.21 - 10:32
(0) по поводу защиты можешь токен прикрутить типа Токен&ТекущаяДата далее это дело в хеш и его шлешь, с другой стороны проверяешь что хеш совпал.
   ДенисЧ
 
2 - 19.05.21 - 10:33
1. Как тебе удобней.
2. Средствами веб-сервера
   fisher
 
3 - 19.05.21 - 10:35
(1) Хм... То есть вся безопасность упирается в секретность "токена". И что в качестве него брать?
   Kassern
 
4 - 19.05.21 - 10:35
(3) а как ты по хешу поймешь, даже если ты его как то перехватил, что там дата вшита?
   fisher
 
5 - 19.05.21 - 10:36
(2) Я пока не знаю, как мне удобнее. Недостаточно опыта работы с XDTO.
   fisher
 
6 - 19.05.21 - 10:36
(4) Криптозащита, опирающаяся на секретность алгоритма, априори ненадежна.
   Kassern
 
7 - 19.05.21 - 10:37
(6) а нужен ли такой уровень защита для вашего сервиса?
   Kassern
 
8 - 19.05.21 - 10:38
(6) а токен можно какой нить 1сный генерить
   ДенисЧ
 
9 - 19.05.21 - 10:38
(5) Тогда делай так, как тебе достаточно опыта.
   fisher
 
10 - 19.05.21 - 10:38
(7) Если это будет дешево, то зачем делать хуже?
   Smit1C
 
11 - 19.05.21 - 10:39
1. структуры
2. какой объём файлов обмена, может и нет смысла их архивировать
3. токены
   Kassern
 
12 - 19.05.21 - 10:40
(10) вы когда обмениваетесь с большинством API сервисов, вам везде крипто про просят? Если дело какаяется финансов, то вопросов нет. А вообще можете делать как вам угодно)
   Kassern
 
13 - 19.05.21 - 10:41
(12) пример с датой в хеше я привел по опыту работы с каким то крупным сервисом доставки, там такая была аунтификация. То ли сдек, то еще кто-то, уже не помню
   fisher
 
14 - 19.05.21 - 10:42
(11)
1. Какие недостатки будут у XDTO? В преимуществах - описанная в одном месте схема данных. А недостатки я пытаюсь осознать.
2. Объем файлов не катастрофический. Но торговые агенты ездят в ебенях, где дай бог устойчивый GPRS поймать.
3. Какие именно токены?
   H A D G E H O G s
 
15 - 19.05.21 - 10:47
(14) недостатком будет тягать wsdl схему каждый раз с сервера, как это делают 99.9% адинесников, вместо того, чтобы закешировать ее в файле при первом обращении в рамках сеанса пользователя.
   fisher
 
16 - 19.05.21 - 10:47
(8) Ну, как запасной вариант пойдет, если ничего лучше не придумается из дешевого. Тупо хэш от айдишника девайса плюс дата - пойдет в принципе. Никто это ломать и даром не будет. Но было бы интересно рассмотреть и варианты получше.
   Василий Алибабаевич
 
17 - 19.05.21 - 10:47
(0)
1. Зависит от передаваемых данных. Все по разному для обменов по планам обмена и отдачи (например) с ЦБ на МП какого-нибудь замороченного отчета.
2. Стандартное ХранилищеЗначения вполне качественно сжимает данные. Не пакеты, а именно данные.
3. Что такое безопасность? Утечка данных? Их подмена?
   H A D G E H O G s
 
18 - 19.05.21 - 10:49
(14) примитивная немного модифицированная xor-ка с солью и хешем отпугнет 99.0 % любопытных. Ключ, конечно, формируем кодом, а не храним в строковой переменной.
   pechkin
 
19 - 19.05.21 - 10:51
(18) ключ каждый раз разный передается или 1 на всю жизнь клиента?
   H A D G E H O G s
 
20 - 19.05.21 - 10:53
(19) 1 на всю жизнь.
   fisher
 
21 - 19.05.21 - 10:54
(15) Хм... Необходимость каждый раз скачивать схему - это минус. На структурах я могу реализовать обратно совместимые версии api.  С wsdl так не выйдет?
(17)
1. И каков характер зависимости?
2. Да, вариант... И заодно "в лоб" данные будет невозможно просмотреть.
3. Невозможность послать запрос на получение данных с неавторизованного устройства
   H A D G E H O G s
 
22 - 19.05.21 - 10:54
(19) это простейшее шифрование с закрытым ключом, без изысков.
   pechkin
 
23 - 19.05.21 - 10:54
(20) тогда можно просто гуид выдать на сервере и не заморачиваться
   Kassern
 
24 - 19.05.21 - 10:54
(19) некоторые сервисы дают 2 ключа, один временный (месяц-два) другой нужен, чтобы получить новый ключ. Когда первый заканчивается, по второму получаешь новый комплект ключей и работаешь.
   H A D G E H O G s
 
25 - 19.05.21 - 10:56
(21) скачиваешь каждый раз, когда возникла ошибка xdto преобразования, что говорит, что формат поменялся.
   H A D G E H O G s
 
26 - 19.05.21 - 10:56
(23) и?
   pechkin
 
27 - 19.05.21 - 10:57
(26) ты же все время передаешь один и тот же токен. зачем тогда сложности - пусть будет гуид.
полученный гуид уже проверяем по базе.
чтоб сложнее было перехватить: хттпс + пост
   Garykom
 
28 - 19.05.21 - 10:57
   fisher
 
29 - 19.05.21 - 10:58
(25) Т.е. ты за XDTO? Других неудобств нет?
   Энштейн 1С
 
30 - 19.05.21 - 10:59
(0) Интересно какими данными обмениваешься с мобильным приложением по содержанию?
 
 
   Kassern
 
31 - 19.05.21 - 10:59
(29) какой объем данных планируется передавать, сколько запросов в секунду будет?
   Василий Алибабаевич
 
32 - 19.05.21 - 10:59
(21) "И каков характер зависимости?"
Например можно с сервера отдавать готовый ТабличныйДокумент. Он сериализуется и его можно затолкать в фабрику. А можно отдавать голые данные и потом сам отчет строить уже в МП. Что может сэкономить трафик. Причем состав "голых данных" может быть произвольным и тут уже фабрика будет тормозом.
   Kassern
 
33 - 19.05.21 - 10:59
(31) если это небольшая поделка, то и нет смысла так заморачиваться
   pechkin
 
34 - 19.05.21 - 10:59
(30) торговые представители же, то бишь прайс и заказы
   fisher
 
35 - 19.05.21 - 11:00
(28) Это будет явно избыточно. Придется же поддерживать идентичные метаданные, не?
   H A D G E H O G s
 
36 - 19.05.21 - 11:00
(27) я никуя не понял про гуид, но мне пофиг.

Https - это обмен рукопожатиями, что несколько печально на gprs. Включи vpnи поработай с https сайтами.
   pechkin
 
37 - 19.05.21 - 11:00
апи обмена конечно должно быть отвязано от метаданных
   Garykom
 
38 - 19.05.21 - 11:01
(32) Если на обоих концах 1С то имеет смысл сначала передавать "готовый ТабличныйДокумент"
Далее если будет тормозить то допилить, просто заранее в архитектуре предусмотреть возможность допилки
   H A D G E H O G s
 
39 - 19.05.21 - 11:01
(29) нет. Быстро, просто, ненапряжно.
   Энштейн 1С
 
40 - 19.05.21 - 11:03
(39) Да нет, я не про техническую сторону вопроса спрашиваю, а какие бизнес процессы автоматизируются чтобы передавать из 1С в мобильное приложение
   fisher
 
41 - 19.05.21 - 11:03
(39) Тогда попробую взять за основной вариант. Тем паче давно хотелось с XDTO плотно поработать.
   Garykom
 
42 - 19.05.21 - 11:04
(35) Не обязательно идентичные но с ними проще
Имена объектов могут не совпадать, а вот реквизиты должны

Можно "свою фабрику" для трансформации написать чтобы и реквизиты перефигачить, банально в Структуру/Соответствие исправить, обратно в JSON и затем штатно в объект
Можно свою сериализацию/десериализацию на простых типах для своих составных с обоих сторон

Короче сам думай как у тебя вариант
   Энштейн 1С
 
43 - 19.05.21 - 11:04
(41) Чем обмениваешься с мобильным приложением? Какие бизнес-процессы используются для обмена 1С и мобильным приложением?
   Василий Алибабаевич
 
44 - 19.05.21 - 11:05
(21) "3. Невозможность послать запрос на получение данных с неавторизованного устройства"
Нужно предусмотреть авторизацию устройства. И тут уже зависит от степени паранои. Можно с какой то периодичностью прописывать на устройства суррогат сертификата. И его отправлять параметром с каждым запросом. Есть вероятность напороться на "протухший" сертификат. Можно с какой-то периодичностью запрашивать "отпечаток" устройства и сверять с эталоном.
   fisher
 
45 - 19.05.21 - 11:06
(42) Не. Мне такие приседания не по вкусу. XDTO железнодорожней, хоть и больше бойлерплейта.
   fisher
 
46 - 19.05.21 - 11:07
(43) Честно - лениво отвечать. Это не суть важно и вряд ли в итоге принесет полезную мне инфу.
   Широкий
 
47 - 19.05.21 - 11:07
Формат: Данные в структуру, структуру в хранилище значения
   Василий Алибабаевич
 
48 - 19.05.21 - 11:11
(47) Видимо самый оптимальный для 1С вариант. Но теряется смысл использования WEB-Сервисов. Остается один сервис с двумя операциями "ПринятьДанные" и "ОтправитьДанные". Никакого разделения на операции, никакого интуитивно понятного API... Правда оно уже и так считается устаревшим.
   pechkin
 
49 - 19.05.21 - 11:11
(48) тестирование такой лабуды многократно усложняется
   Энштейн 1С
 
50 - 19.05.21 - 11:12
(46) Судя по тому, как старательно ты обходишь стороной описание автоматизируемых бизнес-процессов и заботишься о безопасности, рискну предположить, что речь идет о персональных данных
   stopa85
 
51 - 19.05.21 - 11:12
1. Дело вкуса, мне http-сервисы нравятся больше.
2. Не знаю.
3. Идеально - это авторизация по сертификатам на уровне web-сервера. Но есть баги в мобильной платформе и у меня не взлетело.
Пока юзаю так: SSL соедиение (безопастность соединения) + web-сервер проверяет совпадает ли хеш токена, который прислал клиент, с хешами из базы данных. Уже дальше логин/пароль на уровне 1С:Предприятия
   Garykom
 
52 - 19.05.21 - 11:13
(47) это не избавит от преобразования объектов
и если на другой стороне таких объектов (метаданных) нет что делать?
   Василий Алибабаевич
 
53 - 19.05.21 - 11:13
(49) Попробуй потестировать HTTP POST.
   fisher
 
54 - 19.05.21 - 11:13
Резюмируя. Начну с этого:
1. XDTO в JSON
2. Инфу паковать в хранилище значения со штатным сжатием. Возможно сразу подумаю о возможности разбиения пакетов. Вполне вероятно, что захочется и фоточками обмениваться.
3. Токен в виде хэша от айдишника устройства, который будет солиться датой.
   fisher
 
55 - 19.05.21 - 11:14
(48)(51) SOAP я даже не рассматриваю. Через http-сервисы собираюсь.
   Энштейн 1С
 
56 - 19.05.21 - 11:15
(55) через https делай, дефакто это уже стандарт, раз уж упоминал аж криптозащиту
   Василий Алибабаевич
 
57 - 19.05.21 - 11:15
(52) Для простых типов все будет нормально. Для объектных данных возможно заюзать фабрику. Как я и писал в (17)
   fisher
 
58 - 19.05.21 - 11:16
Хотя погоди, wsdl - это ж SOAP. Значит мы выше с HADGEHOGs друг-друга не поняли.
   fisher
 
59 - 19.05.21 - 11:19
Я хочу через http-сервисы, просто сериализацию делать не по "ручной" схеме со структурами, а описать ее через XDTO
   pechkin
 
60 - 19.05.21 - 11:20
упаковку лучше на уровне веб сервера делать
 
 
   Василий Алибабаевич
 
61 - 19.05.21 - 11:22
(60) Оно сможет паковать при отправке данных МП. А кто будет паковать при отправке с МП в ЦБ?
   H A D G E H O G s
 
62 - 19.05.21 - 11:25
Я надеюсь, все понимают, о чем речь.

Автор, если тебе пофиг на то, что твои данные кто-то посмотрит, но тебе важно, чтобы их никто не изменил - просто добавь к данным соль и от всего набора данных+соль сгенери хеш sha256 к примеру и добавь в пакет. На 2 стороне снова сгенери всю эту лабуду и сравни хеши. На уровне типового стандартного https это решается всем многообразием красок сертификатов с удостоверяющими центрами и самоподписью и прочей бабуйней.

Автор, если тебе важно, чтобы данные никто не смотрел - шифруй их. Это наиболее просто сделать xor-кой, которая отпугнет 99% мамкиных хакеров. Закрытый ключ будет храниться на сервере и на МП, если МП не распространяется свободным доступом - то и похер. Но и добавить соль и хеш не повредит, если тебя все таки вскроют. На стандартном уровне это делается с помощью https, который прежде чем отправить пакет полезной инфы, устраивает рукопожатие, которое даже при подключении через vpn уже визуально заметно (пара секунд). Как будет на gprs - хз, когда был gprs, https сайтов еще не было.
   H A D G E H O G s
 
63 - 19.05.21 - 11:26
(62) Токены - шмокены, гуиды.
   Smit1C
 
64 - 19.05.21 - 11:30
(54)
1. Структурой проще)
2. Фотки у тебя не "ужмуться", только текст
3. А как ты будешь получать первоначальный ID устройства ?
   fisher
 
65 - 19.05.21 - 11:31
(62) В шифровании смысла не вижу. Достаточно и того, что тело будет ходить зипованное. А чтобы зная ендпоинт никто не тянул данные - пока остановлюсь на мамкиных токенах.
   H A D G E H O G s
 
66 - 19.05.21 - 11:33
"А чтобы зная ендпоинт никто не тянул данные - пока остановлюсь на мамкиных токенах."
Как ты себе представляешь?
   pechkin
 
67 - 19.05.21 - 11:33
(65) если у злоумышленника будет в руках устройство, то токен утекет, через обычный сниффер
   pechkin
 
68 - 19.05.21 - 11:34
(66) в каждом запросе передаешь токен как параметр
   H A D G E H O G s
 
69 - 19.05.21 - 11:34
(68) И?
   Широкий
 
70 - 19.05.21 - 11:34
(48) Да.  У меня так почти везде и реализовано. Одна операция, два параметра: Тип (строка), Данные(хранилищеЗначения) -в обратку тоже хранилище
   Энштейн 1С
 
71 - 19.05.21 - 11:35
(59) Автоматическая XDTO капризная к данным, рекомендую использовать ручную схему, есть готовые решения ручного преобразования на Инфостарте
   pechkin
 
72 - 19.05.21 - 11:36
(68) если токен не верный, то ничего не возвращать
   H A D G E H O G s
 
73 - 19.05.21 - 11:37
(72) Ну так бы и сказал, что токен для авторизации.
   pechkin
 
74 - 19.05.21 - 11:38
(73) ну это же бай дефолт назначение токена
   Широкий
 
75 - 19.05.21 - 11:40
По защите - двусторонняя авторизация.
Мобильное устройство генеирует уникальный идишник и запоминает его- это идентфикатор конкретного приложения.
Пользователь на мобильнике вводит код и делает первоначальный обмен.
На сервере к этому код ищется разрешенная авторизация: админ включает регистрацию по этому простому коду, причем время авторизации ограничено - у меня 5 мин.

Если разрешенная авторизация найдена - прописывает идитшник от мобильника и отправляется идишник сервера (который генерируется так же на серваке).
В дальнейшем мобильник должен передавать и свой идишник и идишник сервера
   pechkin
 
76 - 19.05.21 - 11:41
(75) это называется генерировать ключ сеанса
   fisher
 
77 - 19.05.21 - 11:46
(64)
1. В чем проще?
2. Ясен пень. Фотки приговаривались про разбитие пакетов.
3. Еще не знаю.
(66) Хэш от посоленного айдишника устройства. Чем солить еще думаю. Датой, например, как предлагали...
   fisher
 
78 - 19.05.21 - 11:47
(73) Да. Токен будет для авторизации.
   H A D G E H O G s
 
79 - 19.05.21 - 11:47
(77) ИД-шники будешь хранить на сервере?
   Smit1C
 
80 - 19.05.21 - 11:48
(75) а зачем ID сервера передавать ?
   fisher
 
81 - 19.05.21 - 11:48
(79) Да. По процедуре начальной инициализации устройства еще думаю.
   Smit1C
 
82 - 19.05.21 - 11:50
(81) в (75) нормальный вариант
   H A D G E H O G s
 
83 - 19.05.21 - 11:51
Токен=Sha256("Мама мыла раму "+НомерРанееВыданногоТокена);
НомерРанееВыданногоТокена=НомерРанееВыданногоТокена+1;
Если НомерРанееВыданногоТокена>10000 Тогда
НомерРанееВыданногоТокена=СлЧисло(10000);
КонецЕсли
УстановитьЗначениеКонстанты("НомерРанееВыданногоТокена",НомерРанееВыданногоТокена);

НаСервере
Для Счетчик=0 По 100000 Цикл
Если ПришедшийТокен=Sha256("Мама мыла раму "+Счетчик) Тогда
....
КонецЦикла
   fisher
 
84 - 19.05.21 - 11:52
(82) Как вариант. Только в авторизации сервера не вижу смысла. Если на такой уровень угроз ориентироваться то и другие вещи надо по-другому делать.
   Kassern
 
85 - 19.05.21 - 11:53
(81) Если по простому, то можно создать справочник в ЦБ, типа КлиентыОбмена. Гуид элемента справочника и будет идентификатором для работы с ним. Так же можешь хранить в этом справочнике особенности работы с ним (матрицу товары, складов и т.д.).
   pechkin
 
86 - 19.05.21 - 11:54
конечно нужен справочник, как минимум там хранить пользователя
   Smit1C
 
87 - 19.05.21 - 11:55
По большому счету если нет htts, то сниффером перехватывается пакет, из пакета берётся токен и отправляется на сервер из любого приложения и сервер даст ответ по этому токену.
Так что смысла особого нет усложнять его.
   fisher
 
88 - 19.05.21 - 11:56
(83) И получить потенциальный гемор с возможностью рассинхронизации счетчиков? Не хочу.
   Garykom
 
89 - 19.05.21 - 11:58
(0) >3. Как решить вопрос безопасности? Токены какие-нить прикрутить? Стоит ли с JWT заморочиться?

Безопасности от чего/кого?
Токены это просто дополнение/усложнение авторизации
Обычный логин/пароль или уникальный токен что удобней смотря что тебе надо и как должно работать
МП твое кто будет юзать? Как ты их будешь различать на сервере/сервисе и т.д.
   pechkin
 
90 - 19.05.21 - 11:58
(89) токены - это не усложнение, а типо пароля
   Garykom
 
91 - 19.05.21 - 11:59
Короче делай как нибудь, один фиг без опыта первый блин будет комом
Как сделаешь потести на реальной нагрузке - и будет понятно как не надо делать ))
   fisher
 
92 - 19.05.21 - 11:59
Пущай токен будет постоянный на день. Снифьте, ломайте. Хрен с ним. Если по-уму легко не сделать, то мне будет достаточно что мамкин кулхацкер не сможет получить данные слепо тыкаясь в ендпоинт.
   Garykom
 
93 - 19.05.21 - 12:00
(90) Чтобы получить токен сначала надо авторизоваться, токены имеют срок жизни потом заново авторизация
Т.е. это именно усложнение системы с целью упрощения и повышения безопасности
Авторизация можно разными способами (логин+пароль, сертификаты укэп и т.д.) а все запросы потом по одному токену (уникальному идентификатору юзера/авторизации)
   Smit1C
 
94 - 19.05.21 - 12:01
(92) вот так бы сразу))
   Garykom
 
95 - 19.05.21 - 12:02
(92) чем тебе не нравится обычная Basic Authorization?
   Garykom
 
96 - 19.05.21 - 12:04
(95)+ Если ты думаешь что пароли перехватит провайдер или хостер или еще кто то это гм и вперед на коммерческую криптографию, которую тоже кому надо расшифрует ))
   pechkin
 
97 - 19.05.21 - 12:06
(96) хттпс же для этого придумали
   pechkin
 
98 - 19.05.21 - 12:07
(92) а как ты будешь кадый день токен менять?
нужен же будет какой то 2 токен для этого, постоянный
   fisher
 
99 - 19.05.21 - 12:14
(95) Морщусь я от неё.
   fisher
 
100 - 19.05.21 - 12:15
(98) Да просто солить каждый день чем-нить разным. Да, стойкость будет в секретности алгоритма. Да и хрен с ним.
  1  2   

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.