1. Как лучше, XDTO в json или структуры в json и почему?
2. Как обеспечить гарантированное сжатие пакетов?
3. Как решить вопрос безопасности? Токены какие-нить прикрутить? Стоит ли с JWT заморочиться?
В ветку призывается Garykom и все желающие :)

(8) Ну, как запасной вариант пойдет, если ничего лучше не придумается из дешевого. Тупо хэш от айдишника девайса плюс дата - пойдет в принципе. Никто это ломать и даром не будет. Но было бы интересно рассмотреть и варианты получше.

(0)
1. Зависит от передаваемых данных. Все по разному для обменов по планам обмена и отдачи (например) с ЦБ на МП какого-нибудь замороченного отчета.
2. Стандартное ХранилищеЗначения вполне качественно сжимает данные. Не пакеты, а именно данные.
3. Что такое безопасность? Утечка данных? Их подмена?

(14) примитивная немного модифицированная xor-ка с солью и хешем отпугнет 99.0 % любопытных. Ключ, конечно, формируем кодом, а не храним в строковой переменной.

(18) ключ каждый раз разный передается или 1 на всю жизнь клиента?

(19) 1 на всю жизнь.

(15) Хм... Необходимость каждый раз скачивать схему - это минус. На структурах я могу реализовать обратно совместимые версии api.  С wsdl так не выйдет?
(17)
1. И каков характер зависимости?
2. Да, вариант... И заодно "в лоб" данные будет невозможно просмотреть.
3. Невозможность послать запрос на получение данных с неавторизованного устройства

(19) это простейшее шифрование с закрытым ключом, без изысков.

(20) тогда можно просто гуид выдать на сервере и не заморачиваться

(19) некоторые сервисы дают 2 ключа, один временный (месяц-два) другой нужен, чтобы получить новый ключ. Когда первый заканчивается, по второму получаешь новый комплект ключей и работаешь.

(21) скачиваешь каждый раз, когда возникла ошибка xdto преобразования, что говорит, что формат поменялся.

(23) и?

(26) ты же все время передаешь один и тот же токен. зачем тогда сложности - пусть будет гуид.
полученный гуид уже проверяем по базе.
чтоб сложнее было перехватить: хттпс + пост

(0) Просто прочитай https://wonderland.v8.1c.ru/blog/serializatsiya-prikladnykh-tipov-1s-predpriyatiya-v-json/?sphrase_id=208400

(25) Т.е. ты за XDTO? Других неудобств нет?

(0) Интересно какими данными обмениваешься с мобильным приложением по содержанию?

(29) какой объем данных планируется передавать, сколько запросов в секунду будет?

(21) "И каков характер зависимости?"
Например можно с сервера отдавать готовый ТабличныйДокумент. Он сериализуется и его можно затолкать в фабрику. А можно отдавать голые данные и потом сам отчет строить уже в МП. Что может сэкономить трафик. Причем состав "голых данных" может быть произвольным и тут уже фабрика будет тормозом.

(31) если это небольшая поделка, то и нет смысла так заморачиваться

(30) торговые представители же, то бишь прайс и заказы

(28) Это будет явно избыточно. Придется же поддерживать идентичные метаданные, не?

(27) я никуя не понял про гуид, но мне пофиг.

Https - это обмен рукопожатиями, что несколько печально на gprs. Включи vpnи поработай с https сайтами.

апи обмена конечно должно быть отвязано от метаданных

(32) Если на обоих концах 1С то имеет смысл сначала передавать "готовый ТабличныйДокумент"
Далее если будет тормозить то допилить, просто заранее в архитектуре предусмотреть возможность допилки

(29) нет. Быстро, просто, ненапряжно.

(39) Да нет, я не про техническую сторону вопроса спрашиваю, а какие бизнес процессы автоматизируются чтобы передавать из 1С в мобильное приложение

(39) Тогда попробую взять за основной вариант. Тем паче давно хотелось с XDTO плотно поработать.

(35) Не обязательно идентичные но с ними проще
Имена объектов могут не совпадать, а вот реквизиты должны

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

Короче сам думай как у тебя вариант

(41) Чем обмениваешься с мобильным приложением? Какие бизнес-процессы используются для обмена 1С и мобильным приложением?

(21) "3. Невозможность послать запрос на получение данных с неавторизованного устройства"
Нужно предусмотреть авторизацию устройства. И тут уже зависит от степени паранои. Можно с какой то периодичностью прописывать на устройства суррогат сертификата. И его отправлять параметром с каждым запросом. Есть вероятность напороться на "протухший" сертификат. Можно с какой-то периодичностью запрашивать "отпечаток" устройства и сверять с эталоном.

(42) Не. Мне такие приседания не по вкусу. XDTO железнодорожней, хоть и больше бойлерплейта.

(43) Честно - лениво отвечать. Это не суть важно и вряд ли в итоге принесет полезную мне инфу.

Формат: Данные в структуру, структуру в хранилище значения

(47) Видимо самый оптимальный для 1С вариант. Но теряется смысл использования WEB-Сервисов. Остается один сервис с двумя операциями "ПринятьДанные" и "ОтправитьДанные". Никакого разделения на операции, никакого интуитивно понятного API... Правда оно уже и так считается устаревшим.

(48) тестирование такой лабуды многократно усложняется

(46) Судя по тому, как старательно ты обходишь стороной описание автоматизируемых бизнес-процессов и заботишься о безопасности, рискну предположить, что речь идет о персональных данных

1. Дело вкуса, мне http-сервисы нравятся больше.
2. Не знаю.
3. Идеально - это авторизация по сертификатам на уровне web-сервера. Но есть баги в мобильной платформе и у меня не взлетело.
Пока юзаю так: SSL соедиение (безопастность соединения) + web-сервер проверяет совпадает ли хеш токена, который прислал клиент, с хешами из базы данных. Уже дальше логин/пароль на уровне 1С:Предприятия

(47) это не избавит от преобразования объектов
и если на другой стороне таких объектов (метаданных) нет что делать?

(49) Попробуй потестировать HTTP POST.

Резюмируя. Начну с этого:
1. XDTO в JSON
2. Инфу паковать в хранилище значения со штатным сжатием. Возможно сразу подумаю о возможности разбиения пакетов. Вполне вероятно, что захочется и фоточками обмениваться.
3. Токен в виде хэша от айдишника устройства, который будет солиться датой.

(48)(51) SOAP я даже не рассматриваю. Через http-сервисы собираюсь.

(55) через https делай, дефакто это уже стандарт, раз уж упоминал аж криптозащиту

(52) Для простых типов все будет нормально. Для объектных данных возможно заюзать фабрику. Как я и писал в (17)

Хотя погоди, wsdl - это ж SOAP. Значит мы выше с HADGEHOGs друг-друга не поняли.

Я хочу через http-сервисы, просто сериализацию делать не по "ручной" схеме со структурами, а описать ее через XDTO

упаковку лучше на уровне веб сервера делать

(60) Оно сможет паковать при отправке данных МП. А кто будет паковать при отправке с МП в ЦБ?

Я надеюсь, все понимают, о чем речь.

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

Автор, если тебе важно, чтобы данные никто не смотрел - шифруй их. Это наиболее просто сделать xor-кой, которая отпугнет 99% мамкиных хакеров. Закрытый ключ будет храниться на сервере и на МП, если МП не распространяется свободным доступом - то и похер. Но и добавить соль и хеш не повредит, если тебя все таки вскроют. На стандартном уровне это делается с помощью https, который прежде чем отправить пакет полезной инфы, устраивает рукопожатие, которое даже при подключении через vpn уже визуально заметно (пара секунд). Как будет на gprs - хз, когда был gprs, https сайтов еще не было.

(62) Токены - шмокены, гуиды.

(54)
1. Структурой проще)
2. Фотки у тебя не "ужмуться", только текст
3. А как ты будешь получать первоначальный ID устройства ?

(62) В шифровании смысла не вижу. Достаточно и того, что тело будет ходить зипованное. А чтобы зная ендпоинт никто не тянул данные - пока остановлюсь на мамкиных токенах.

"А чтобы зная ендпоинт никто не тянул данные - пока остановлюсь на мамкиных токенах."
Как ты себе представляешь?

(65) если у злоумышленника будет в руках устройство, то токен утекет, через обычный сниффер

(66) в каждом запросе передаешь токен как параметр

(68) И?

(48) Да.  У меня так почти везде и реализовано. Одна операция, два параметра: Тип (строка), Данные(хранилищеЗначения) -в обратку тоже хранилище

(59) Автоматическая XDTO капризная к данным, рекомендую использовать ручную схему, есть готовые решения ручного преобразования на Инфостарте

(68) если токен не верный, то ничего не возвращать

(72) Ну так бы и сказал, что токен для авторизации.

(73) ну это же бай дефолт назначение токена

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

Если разрешенная авторизация найдена - прописывает идитшник от мобильника и отправляется идишник сервера (который генерируется так же на серваке).
В дальнейшем мобильник должен передавать и свой идишник и идишник сервера

(75) это называется генерировать ключ сеанса

(64)
1. В чем проще?
2. Ясен пень. Фотки приговаривались про разбитие пакетов.
3. Еще не знаю.
(66) Хэш от посоленного айдишника устройства. Чем солить еще думаю. Датой, например, как предлагали...

(73) Да. Токен будет для авторизации.

(77) ИД-шники будешь хранить на сервере?

(75) а зачем ID сервера передавать ?

(79) Да. По процедуре начальной инициализации устройства еще думаю.

(81) в (75) нормальный вариант

Токен=Sha256("Мама мыла раму "+НомерРанееВыданногоТокена);
НомерРанееВыданногоТокена=НомерРанееВыданногоТокена+1;
Если НомерРанееВыданногоТокена>10000 Тогда
НомерРанееВыданногоТокена=СлЧисло(10000);
КонецЕсли
УстановитьЗначениеКонстанты("НомерРанееВыданногоТокена",НомерРанееВыданногоТокена);

НаСервере

Для Счетчик=0 По 100000 Цикл
Если ПришедшийТокен=Sha256("Мама мыла раму "+Счетчик) Тогда
....
КонецЦикла

(82) Как вариант. Только в авторизации сервера не вижу смысла. Если на такой уровень угроз ориентироваться то и другие вещи надо по-другому делать.

(81) Если по простому, то можно создать справочник в ЦБ, типа КлиентыОбмена. Гуид элемента справочника и будет идентификатором для работы с ним. Так же можешь хранить в этом справочнике особенности работы с ним (матрицу товары, складов и т.д.).

конечно нужен справочник, как минимум там хранить пользователя

По большому счету если нет htts, то сниффером перехватывается пакет, из пакета берётся токен и отправляется на сервер из любого приложения и сервер даст ответ по этому токену.
Так что смысла особого нет усложнять его.

(83) И получить потенциальный гемор с возможностью рассинхронизации счетчиков? Не хочу.

(0) >3. Как решить вопрос безопасности? Токены какие-нить прикрутить? Стоит ли с JWT заморочиться?

Безопасности от чего/кого?
Токены это просто дополнение/усложнение авторизации
Обычный логин/пароль или уникальный токен что удобней смотря что тебе надо и как должно работать
МП твое кто будет юзать? Как ты их будешь различать на сервере/сервисе и т.д.

(89) токены - это не усложнение, а типо пароля

Короче делай как нибудь, один фиг без опыта первый блин будет комом
Как сделаешь потести на реальной нагрузке - и будет понятно как не надо делать ))

Пущай токен будет постоянный на день. Снифьте, ломайте. Хрен с ним. Если по-уму легко не сделать, то мне будет достаточно что мамкин кулхацкер не сможет получить данные слепо тыкаясь в ендпоинт.

(90) Чтобы получить токен сначала надо авторизоваться, токены имеют срок жизни потом заново авторизация
Т.е. это именно усложнение системы с целью упрощения и повышения безопасности
Авторизация можно разными способами (логин+пароль, сертификаты укэп и т.д.) а все запросы потом по одному токену (уникальному идентификатору юзера/авторизации)

(92) вот так бы сразу))

(92) чем тебе не нравится обычная Basic Authorization?

(95)+ Если ты думаешь что пароли перехватит провайдер или хостер или еще кто то это гм и вперед на коммерческую криптографию, которую тоже кому надо расшифрует ))

(96) хттпс же для этого придумали

(92) а как ты будешь кадый день токен менять?
нужен же будет какой то 2 токен для этого, постоянный

(95) Морщусь я от неё.

(98) Да просто солить каждый день чем-нить разным. Да, стойкость будет в секретности алгоритма. Да и хрен с ним.

(97) не спасает от подмены провайдером (или еще кем на линии), он тебе подсунет фишинг сертификат посередине, будешь думать что с конечным а по факту через прокси общаешься
и для конечного тоже

(101) это сертификат нужно в доверенные добавить ручками, иначе не сработает

(100) тогда придется синхронизировать соль как то

(103) Говорю же. Алгоритм ее получения будет одинаков на сервере и клиенте.

(102) если нет принудительного указания сертификата то он же с сервера берется
и промежуточный тебе подсунет свой вместо конечного и конечному свой подсунет вместо твоего и будет посередине сидеть на линии перешифровывая

(105)+ этим способом в крупняках инет контролируют сотрудников, даже на https сайтах

(106) ну в крупняках то как раз и ручками могут установить нужный серт

(107) ты упал что ли? свой ноут приносишь, к корп вифи подрубаешь, на сайт миста.ру заходишь и смотря сертификат в браузере вместо  "RapidSSL RSA CA 2018" видно нечто совершенно другое

Чёт я уже передумал XDTO. XML в json вызывает эстетические спазмы.

(108) и что браузер даже не ругается?

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

(109) есть такое
но зато быстро и просто делать

(109) Ну ты же его лучше знаешь... Откуда позывы?

(113) Я говорил не это. Я говорил, что хотел узнать его получше. Да видать не судьба.

Будут структуры/массивы и рукопашные фабрики.