Форум

Аналогично. Хотя бы с XLSX разобраться, для начала. Трата времени на интеграцию в эти дни разбитым корытом попахивает.

Требование по подключению к ГИС ЖКХ - вполне рыночное обстоятельство: сильные выживут, слабые помрут.

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

Если ТСЖ разрабатывает свой софт, ведёт свои базы данных и т.п., то оно и есть информационная система. А если у нас ТСЖ на четыре квартиры, то ему и XLS хватит.

Ок, принято: на рынке много информационных систем, и поскольку их разработчики массово не умеют обмениваться данными в онлайне и учиться не хотят, нужно предоставить им что-то более традиционное, вроде XML через файлы. С учётом того, что внедрение отодвигается, почему бы и не сделать.
Но некоторые ведь и XML не умеют, и просят TXT (прямо в этой теме).

Я так понимаю, что XLSX - решение для ТСЖ на четыре квартиры. Заполнили ручками, отправили, получили список ошибок, исправили (опять же ручками, за две минуты), отправили снова. А если у нас ошибочные данные генерирует софт, то так не получится: нужно звать программиста, и исправление откладывается минимум на день (а в худшем случае - на несколько месяцев). Если есть программист, то нужен и тестовый стенд.

Да, кстати. Вы писали, что с ГИС ЖКХ не работали. Но поинтересоваться, что же там в интеграции разработчики предлагают, всё же и Вам стоило бы. Прилагаю архив с тремя документами общим объёмом в 1700+ страниц. Там не просто "загрузка/выгрузка файлов" реализована. Там десятки Web-сервисов с кучей разных удалённо вызываемых методов. Оцените "простоту" взаимодействия!

Умный софт должен сам анализировать ошибки. И если это ошибка оператора - подсказывать ему, что надо исправить. Моя программа обслуживает несколько УК и десятки ТСЖ. Ни к кому никогда не езжу. Только телефон, email и - иногда - Ammyy Admin.

Отправлено спустя 10 минуты 41 секунды:
Это - искусственно созданное обстоятельство. Малый бизнес (основа среднего класса) и без того всюду выдавливается с рынка монополиями. Просто тут наблюдаем очередной удар ему по башке.
Хотелось бы надеяться, что в итоге пойдут. Но только не мне лично, а многим тысячам мелких УК и ТСЖ и самозанятым программистам, их обслуживающим.

А не похоже ли это на монополию, это требование?

Отправлено спустя 3 минуты 6 секунды:

Это почти про меня. XML я умею, но описание его содержимого оставляет желать лучшего.

Отправлено спустя 4 минуты 21 секунды:
А у меня на первом месте YandexDisk, на втором - телефон.

Я уже тут писал, что на данный момент система авторизации на ГИС ЖКХ заслуживает самое мягкое определения "крайне непродуманная". В стране все еще много тех, кто не зарегистрирован на Госуслугах - в основном это пенсионеры. А пенсионеров - треть населения страны. И они очень часто являются формальными владельцами. Итого, минимум треть квартир даже в принципе (не обращая внимание на то, что Росреестр привязывается как попало) не могут зайти и посмотреть, что же там УО внесли.
Это конечно была шутка, забавное преувеличение. но! в каждой шутке как известно только доля шутки. ЭП на файлы передаваемые в ЛК не ставится, кто отправитель заранее известно, так что SOAP от XML практически не отличается в этом случае.
По пунктам:
1) Более половины реализации SOAP одинаково не только в рамках ГИС ЖКХ, но и вообще всех российских ФГИС (все что вне Body по большому счету описано SOAP, отличий не так уж много). То есть что разработчиков множество это плохо, а что государство не предложит единую реализацию SOAP, на которую могли бы ориентироваться те же разработчики будущих ФГИС, это нормально - как хотите так и плывите. Правильно Вас понимаю?
2) небезопасно, согласен. Но все криптопровайдеры тоже в своем составе имеют DLL, естественно подписанные и сертифицированные ФСБ. Им вы доверяете? И при этом лично звонили проверяли подлинность сертификата? Ну и прекрасно, используем их.
Собственно для данной DLL (обертки XML в SOAP, добавление подписи, отправки SOAP на сервер ГИС) нет необходимости работать с приватными ключами напрямую (даже скорее посторонняя функция, зачем изобретать велосипед и реализовывать криптографические примитивы) - можно вычислить необходимые значения либо через сертифицированный криптопровайдер (который, "зараза", формирует cades-bes в отсоединенной ЭП файла, но тем не менее сам не умеет формировать xades-bes внутри XML) либо через сертифицированную версию OpenSSL (как рекомендуется в статьях на хабре). Плюс цифровая подпись DLL, что ее никто не изменял и она сама ключи не ворует. Понятно, если бы библиотека была подписана подписью ГИС ЖКХ или КриптоПро к ней было бы больше доверия, чем к "левому" разработчику, потому и просим.
Естественно, будет ли пользователь использовать сертифицированный криптопровайдер, сертифицированные бинарные файлы OpenSSL (и платить денежку) или общедоступные несертифицированные или соберет свою сборку - остается на совести администратора информационной безопасности организации пользователя. Нет смысла "не выпускать джинна из бутылки" - кто захочет несертифицированный, сделает и по тем статьям на хабре.
3) На Linux есть аналог DLL - SO библиотеки. Если компилятор кроссплатформенный, то сделать библиотеку для Linux примерно так сложно как передать параметр TargetOs и ссылки на библиотеки взять в управляющие комментарии (в кроссплатформенных компиляторах как правило уже есть билды стандартных Unit с использованием библиотек поддерживаемых операционных систем, нужно только Unit собственного сочинения перестроить под них). Тем не менее, у меня, например, нет планов поддерживать библиотеку на *nix системах, так как у меня нет возможности составить корректные представления о криптопровайдерах на *nix и написать соответствующие Unit.
4) Здравствуйте, при всем уважении, а кроме семейства Си языки какие-то знаете? У меня например мои все DLL на Паскале. Главное, что бы формат параметров можно было описать на любом языке - неважен язык программирования разработчика DLL. Это дает огромное преимущество по сравнению с проектами которые все делают именно на C# или Java. Не считая отсутствия громоздкого dotNet. Это компенсирует некоторые неудобства. Написать объект на вашем языке программирования когда уже есть реализация кода объекта в виде отдельных функций DLL тоже простая задача - все основные функции операционной системы Windows как раз содержатся в DLL, тем не менее работаете с ними через объекты.
Если же Вы имеете ввиду ООП при работе самой библиотеки, то огромное количество COM объектов как раз используют фабрики экземпляров в виде DLL и OCX TLB (расширение не особо имеет значение - по сути это тоже внешний исполняемый код, подгружаемый программой). Но COM объекты как раз и привяжут нас к Windows. dotNet полагаю тоже?
5) Ошибки есть везде и зона ответственности не разграничена, согласен. Но посмотрим, в среднем процессе Windows 7 вовлечены более чем 100 библиотек - не потому что разработчик программы их все загрузил, а потому системные и околосистемные библиотеки тянут за собой огромное количество зависимостей. В этом смысле, если добавится еще одна библиотека, погоды это не сделает. Для этого есть современные средства отладки собирающие данные активности на момент сбоя во всех потоках процесса. Определить, что вылетело при выполнении такой-то функции - на раз.
Тут хочу высказаться о языке программирования, на котором сделана библиотека - компиляторы Паскаля как раз славятся тем, что при загрузке модуля (будь то программа или библиотека) сразу же запрашивается память у системы "про запас", не через getmem, а как еще один сегмент наряду с кодом и данными (в них сразу записаны значения) - сегмент "кучи" (значения не записаны, заполнен "мусором" из оперативной памяти). По умолчанию это 8 мегабайт, мало по нынешним меркам, но на хранение результатов криптооперации - с головой хватит. Заранее объявленные глобальные переменные сюда не входят - один раз была нужда и объявил глобальный многомерный массив, потянувший на гигабайт - и все это скомпилировалось в сегменте данных. Если памяти не хватит библиотека не загрузится вообще и будет ясно - вывалилось до загрузки библиотеки и обработать это корректно задача использующей программы. Если память есть, то все загрузится и пока запас не исчерпан, никакой дополнительной памяти у системы не запрашивается и всю обработку правильности использования памяти в сегментах ведет стандартный код, вставленный компилятором. То есть со внутренней "кучей" можно что угодно делать - это повлияет на корректность работы библиотеки, но на работоспособность программы, использующей библиотеку, и системы это не повлияет. Хотя конечно памяти потребляет больше, по сравнению с запросом и освобождением у системы памяти для каждого объекта, но так надежнее.
С использованием данных, переданных основной программой гораздо сложнее, но и тут можно подстелить соломку, проверяя все указатели системной функцией (IsBadReadPtr IsBadWritePtr кажется - для своих программ не делал, но если распространять библиотеку, то нужно делать), как это делает само ядро операционной системы, и возвращая код ошибки "неправильный указатель", если проверка не пройдена. Лезть в память программы, если библиотеку об этом не просили и не дали правильный указатель - заведомо ошибочное дело, нет разницы в одном мы адресном пространстве или в разных.
6) проблемы обновления DLL абсолютно такие же, как и у программы, а именно - что заменить файл модуля, который запущен в данный момент, мягко говоря, непросто. Плюс при этом нужно убедиться, что замена не испорчена, а то и подписана ЭП. Проще в том плане, что объем библиотеки мал. Апплеты панели управления с расширением CPL - все те же DLL, но написанные по определенным требованиям и выводящие пользователю диалоговые окна. В том числе среди них есть такие, что реализуют функцию обновления какой-либо программы. Есть и другие средства решения: например можно функцию обновления вызывать в самой DLL при инициализации. Либо экспортировать функцию обновления отдельно, а в комплекте распространять bat файл, запускающий rundll32 для загрузки библиотеки и выполнения функции.
Насчет этого - никаких проблем, просто ЭЦП должна быть отсоединенной, в виде отдельного файла с расширением sig. Заметьте, в ту же налоговую (и из нее тоже) передается отсоединенная ЭЦП. Еще краем уха слышал, сейчас можно подписать VBScript, тоже по сути текстовый файл, в подробности не вникал пока. С остальным соглашусь, формат должен быть описан точно.
Это конечно так, однако вот так посмотришь что в одном регионе "горячее водоснабжение", в другом "подогрев воды" и так далее и тому подобное. Программа, учитывающая все нюансы будет огромной и соответственно пропорционально количеству кода возрастет количество ошибок. Собственно именно это и видим на примере ГИС. Хотя наверно тоже можно поделить на библиотеки

Мне очень понравилось заявление, что, мол, в ЕСИА зарегистрировано более 30 млн человек и все они могут легко "провалиться" в ЛК физ.лиц ГИС. А вот о том, какой процент из этих 30 млн являются собственниками, скромно промолчали.

Готов частично профинансировать разработку веб сервиса для 1с, а также выступить разработчиком ТЗ.

Думаю процентов 10-20 Молодежь, которая все умеет, но ничего пока не имеет
Вот и наши люди начали с инакомыслящими разговаривать

Вообще-то, тема - не о том. Лучше бы отдельную завести.

Финансы - двигатель прогресса и ускоритель реакции.

1c это немного другое, там специфический Visual Basic с русским акцентом. Конечно это достойно отдельного обсуждения, работающих в 1с немало и есть платный модуль для гисгмп, так что есть с чего начать. Кстати, модуль для ГИС жкх вроде бы тоже есть, в соседнем разделе обсуждали как замечательно все синхронизируется с 1с, но кажется выгрузка-загрузка вручную. Вот тут начали что-то делать по автоматизации, но похоже пока не очень-то ладится и им посоветовали тоже сделать сервис на C#. Я за 1с не возьмусь - так как там специфическое обновление форм и как представлю что это все править после каждой смены версии форматов гис жкх, становится дурно.
Теоретически,если все же сделать DLL автоматической смены отчетов, можно подумать как прикрутить к 1с. Пока что проектирую DLL для обертки и отправки уже готовых данных, до подготовки самих отчетов еще не скоро дело дойдет.

Из 1С7.7 выгрузил через Excel 2003 (плюс конвертор) 80 квартир в шаблон МКД. ГИС принял, обработал.
Формат MXL да, очень хочется.

Прошу прощения за поздний ответ. Я сейчас в командировке, со временем напряг.
Чтобы софт стал умным и хотя бы не делал свои ошибки (бог с ними, с ошибками оператора), этот софт надо сначала отладить. Желательно, не на "боевых" данных, а на тестовых.
Собственно, ГИС ЖКХ сейчас кривая в том числе и потому, что отлаживать её было не на чем.
Обстоятельства вполне естественные: необходимость навести порядок в ЖКХ - объективна, а компьютеризация процессов способствует выявлению узких мест (что будет после выявления - вопрос отдельный). И ликвидация малого бизнеса в том виде, в котором он сейчас существует - тоже процесс естественный.

Отправлено спустя 6 минуты 29 секунды:
Нет, не похоже. У нас не одна сильная команда программистов.

На это мне пока нечего ответить. Но это уже _другая_ проблема.

Согласен. И где же специальные "средства отладки" при загрузке информации через XLSX? Их просто нет. Только ответные диагностики. Вот, их-то и надо показывать оператору. Другого выхода нет. И если диагностики связаны с программными ошибками, то потребуется, конечно, доработка программы. В иных случаях реагировать придётся оператору.
Здесь - категорически не соглашусь. Но это - тема не для нашего форума.

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

Вообще-то если по уму, то следовало бы требовать подпись и от файлов, передаваемых через ЛК.

Реализации SOAP предлагает не государство, а разработчики языков программирования и библиотек.

Плевать на сертификат ФСБ. Главное, чтобы софт, установленный на той машине, с которой есть доступ к приватному ключу, не умел втихаря генерировать подпись для текста "Продаю всё своё имущество имяреку за 1 (один) рубль".

Деньги давать не пробовали? А то вот у меня к еде из магазина больше доверия, чем к еде с помойки, но это же не причина, чтобы попрошайничать.

С ними - ровно те же самые проблемы, что и с виндовыми dll. И по тем же техническим причинам.

Ага, сейчас.
- Разные языки программирования - это причина существования в компиляторах от MS ключевых слов __stdcall и __cdecl.
- Предположим, у нас есть простенькая функция:
__declspec(dllexport) std::string foo(const std::string &d) {return d;} Сможете Вы вызвать её из Паскаля? Вряд ли. Я именно об этом. А сишный интерфейс (const char *) - устарел и неудобен.

SOAP нас к винде не привязывает. А com-объекты - да, привязали бы не хуже dll.

Те DLL, которые грузятся при старте обычной программы, в основном созданы MS - компанией с очень серьёзным подходом к качеству ПО. В России аналогов нет. Да и у MS регулярно находят проблемы.

Это если оно вылетело. А если memory corruption? Такое тоже ищется, но ох не сразу.


Это всё детали реализации. Пока не решены проблемы с интерфейсами, не вижу смысла это обсуждать.

Технически - такие же. Юридически - нет: если нет DLL, то техподдержка ГИС ЖКХ избавляется от разговоров про эту DLL.

Что-то я потерял нить разговора. Помнится, начинали мы с того, что злые разработчики ГИС ЖКХ заставляют бедных разработчиков подключаться к своим тестовым стендам. Я говорил, что без тестового стенда невозможно выловить ошибки софта, работающего с ГИС ЖКХ, и этот стенд - не зло, а полезная штука.

Если Вам диагностики не хватает - ну ок, это может быть проблемой. Хотя тут тоже аккуратно надо, чтобы не дойти до диагностики вида "Ошибка в 13 бите пароля".

Ну, не надо утрировать. Перечитайте всё, написанное выше. Особое внимание обратите на объём документации по взаимодействию ИС с ГИС через Web-сервисы. Сам подход никак не предполагает, что каждое ТСЖ будет регистрироваться как "собственная ИС" (в понимании разработчиков ГИС), проходить испытания на стенде и выходить на промышленную эксплуатацию. А не хотите так - долбите ручками в Экселе. Такая вот "альтернатива". Они никак не предполагали, что куча народу будет искать средства автоматического формирования XLSX-файлов...

Впрочем, я уже повторяюсь. И предлагаю не толочь воду в ступе. Ваша позиция мне понятна. Надеюсь, что моя Вам - тоже.

Что-то я такой опции не увидел. И никаких "наводок" на это тоже. Поищу еще, если получится - премного благодарен.
Это да. но раз полагаются на ПЭП Госуслуг, нам проще.
Согласен, но государство покупает реализации SOAP для центральных узлов СМЭВ - ничего не мешает включить в ТЗ пункт про библиотеку для свободного распространения. Бог с реализацией, но на данный момент каждая ГИС дополняет формат SOAP как в голову придет разработчикам ГИС. Минкомсвязь могло бы утвердить правила, уточняющие как именно дополнять стандарт - в какое место файла располагать ЭП, как стандартно указывать отправителя/получателя и тд. В конце концов, Little Endian или Big Endian использовать в кодировке ЭП. Это явно задача государства, а не разработчиков, которые реализуют только один вариант, но при этом никто не может внятно объяснить, почему нельзя по другому- в ГОСТ это не указано. Тем не менее, другой вариант возвращается с ошибкой - "Неверная ЭП".
Конечно, но это другая платформа, то есть привязка к Windows - мнимая. Тот же код программы, который напишете на Си будет скомпилирован и упакован в разный формат исполняемых файлов для разных операционных систем.
Что это изменит? Качество вряд ли будет выше пропорционально сумме. Другой вопрос - кому? Реализация SOAP в ГИС довольно неполная и кривоватая, нет никакой гарантии, что другая неполная же реализация других разработчиков совпадет "по кривизне" и будет работать. В магазине Вам тоже могут предложить Столичный хлеб, когда вы пришли за Бородинским. Даже если с одной ГИС будет, хотелось бы универсальную библиотеку для всех федеральных ГИС. А если тем же, кто разрабатывал ГИС, то их компании и так уже заплатило государство (а государство это взяло из налогов и штрафов, то есть с нас с Вами в том числе) и совершенно немалые суммы. Честно, меня просто жаба задавит добавлять к тем суммам.Знаю. Я в это когда-то вникал и смогу вызвать функцию, хотя возможно это займет время, чтобы разобрать код на Си и подобрать аналогичное описание объекта на Паскале. Либо подключить другую библиотеку того же языка, реализующую этот объект - если не вникать как объект устроен, а просто скормить, что передали и получить, что нужно либо наоборот. Как правило ключевые слова меняют порядок аргументов, так что для функции с одним аргументом мало что изменится, пример неудачен.
(я таки на Си не пишу, но немного разбираю, char * - указатель на буфер сразу, std::string &d вроде бы указатель на объект из которого еще надо получить указатель на буфер через c_str и длину через length/size, в этом смысле достаточно каким-то образом реализовать или подключить c_str и size. Скорее даже не так - объекты обычно хранят указатели на реализованные методы объекта, то есть достаточно найти в объекте нужный указатель на уже реализованную функцию c_str и узнать как ей передать объект). В общем, я не так хорошо знаю Си, а Вы похоже вообще не знаете Паскаль, примеры тут бессмысленно обсуждать.
Для информации - в Паскале таких ключевых слов тоже с десяток, включая вышеназванные - это раз. Если ни одно не подойдет, то никто не отменял возможность сделать "оберточную функцию" и вставить в код на Паскале операторную скобку asm .. end и написать внутри код ассемблера для передачи параметров и вызова импортируемой функции - это два. Конечно, при этом вся типизация коту под хвост и возможны ошибки. Но, надеюсь Вы не считаете, что разные языки для передачи параметров компилируют какой-то иной машинный код, несовместимый с ассемблером под ту же архитектуру процессора? Можно еще проще, просто используем stdcall - большинство языков умеет работать с системными библиотеками. Итого: остается просто описать заголовки (ну или оберточные функции) на нужном языке, а проблема не стоит выеденного яйца - решаем один раз, потом миллионы раз вызываем функцию.
Да и большая часть из них именно переполнение буфера, то есть по сути именно memory corruption. Это именно болезнь языка Си и прямого использования char * - даже хотя есть вариант функций с указанием размера, многие даже в Майкрософт на это плюют и используют функции без ограничения размера либо неправильно вычисляют ограничение. В Паскале все жестче - например, обычный string (shortstring в моей IDE) ограничен 255 байтами и (используя стандартные функции, без обращения к символам по номеру и махинаций с указателями) 256-ой записать невозможно в принципе - при любой записи берется минимум из ограничения и ожидаемого размера данных. Конечно, 255 байт откровенно сказать мало, но тут ничего не мешает найти исходник встроенного типа по образцу сделать собственный тип скажем на 10 мегабайт и тоже жестко вшить в него ограничение.Учитывая, выше про stdcall, не вижу проблем. Интерфейс всегда можно доработать, если Вам удобнее получать строчку в std::string чем в голом char * то это предмет переговоров о включении дополнительной "оберточной" функции. Либо мне тоже std::string понравится и я портирую объект на Паскаль. Но тут как раз может вылезти что объект не такой уж и std (стандартный), а отличается в разных Си.я и не говорил, что это именно техподдержка ГИС ЖКХ будет по DLL по SOAP работу вести, так как федеральных ГИС много, и желательно общую библиотеку. Есть ситуационный центр электронного правительства. Как вариант, сама компания-разработчик библиотеки. А вот конкретно по библиотеке отчетов для ГИС ЖКХ, там конечно техподдержка этой ГИС и тут все понятно (в смысле наоборот непонятно, с чего начинать).

Для разработчиков на Паскале (Delphi) напомню, что строковые переменные и в DLL и в программе должны иметь тип shortstring. Все другие строковые типы, указатели на них, а так же примочки в виде делфийских DLL не работают или работают некорректно!

Из-за этого очень сильные тормоза!

Конечно они должны иметь одинаковый тип, точнее одинаково описанный. Хм, никогда не было проблем с этим. Ни со своими DLL, ни с системными. Сейчас перепроверю какой тип использовался, насколько помню pchar и все дела. Точнее, совместимый с ним собственный тип pathstr=array[1..260] of char и запись #0 в конце, от которого брался указатель. Что со мной не так? Замечу, что это не был объект и соответственно методы работы с ним реализовались независимо на каждой стороне, операторы не переопределялись. Конечно, так работать неудобно.
Другой вопрос, что типы-объекты нужно правильно (ре)конструировать и правильно передавать - просто положиться на среду программирования не всегда получится. Паскаль обычно использует как ссылку на себя внутри объекта (и она передается в метод в регистре процессора, а не через стек) ссылку на данные объекта (а не на начало памяти объекта ) - с одной стороны от нее (адрес в большую сторону, насколько помню) данные объекта, с другой стороны (в меньшую сторону соответственно) - адреса функций и процедур (методы) объекта. Если описание объекта не совпадает (методы и данные не совпадут после передачи) либо если передать ссылку на данные вместо объекта целиком и наоборот (так при передаче адресов методов может не оказаться в объекте на стороне-получателе), то ничего работать не будет.
Поэтому (если не заморачиваться) обычно и нужно избегать передавать объекты. Но, если я реконструирую объект после получения (исправлю адреса методов и поставлю указатель на нужное место), то проблем быть не должно. В этом смысле общее адресное пространство между программой и библиотекой скорее плюс, ссылки на методы должны быть все еще действительными после передачи. Однако, тут важно помнить, что адрес самой DLL может измениться при загрузке библиотеки, и если реализация объекта находится в DLL, то изменится и адрес реализации метода. Поэтому адрес метода нужно не прописывать конкретной цифрой, а импортировать либо находить системной функцией (GetProcAddress) после загрузки библиотеки.Ну, в смысле, понятно, что можно получить описания схем и их проанализировать на предмет новых полей, изменений формата, удалений полей. Но далее нужно как-то связать с получаемыми из базы данных УО/ТСЖ данными. Пока придумался такой вариант - после обновления документация анализируется и структура тегов вроде преобразуется в имя переменной: в начале и конце строки ставится $, имена тегов (можно без пространств имен, но тогда еще отдельно нужно имена пространств передавать и сопоставлять плюс проверять ссылки на них) соединяются точками согласно иерархии, получится строка вроде$soapenv:Body.pay:importNotificationsOfOrderExecutionRequest.pay:NotificationOfOrderExecutionType.pay1:RecipientInfo.org:INN$ (с пространствами) либо $Body.importNotificationsOfOrderExecutionRequest.NotificationOfOrderExecutionType.RecipientInfo.INN$ (без пространств), формируется и где-то сохраняется шаблон в котором вместо значения подставлена такая строка (и так по всем значениям). Можно конечно как-то сокращать имена до $RecipientInfo.INN$ например, а то в shortstring не впишемся, но тогда нужно сопоставлять сокращенные и краткие имена. Зато попутно можно сопоставлять новое положение переменной в иерархии старому краткому имени и это может делать "опытный пользователь", не обязательно программист.
По запросу от библиотеки программа может получить список массив имен нужных переменных (без $), массив их обязательности и версию для конкретного шаблона SOAP запроса.
При формировании из программы передаются два массива строк для формирования отчета - один с именами переменных (без $), другой со соответствующими значениями переменных (значения уже заранее переведены в строку). Функция проверяет, что все переменные заполнены либо остались незаполнены необязательные (если не хватает выдает ошибку и, допустим, массив нехватающих переменных и их обязательность), убирает пустые необязательные и формирует готовый для отправки SOAP запрос, соответствующий новому шаблону.
Результат программа проверяет, что там нет "Продаю имущество имярек за 1 рубль". Можно, например, выводить пользователю для визуальной оценки (если XML плохо смотреть, то можно в библиотеку еще формирование версии для печати заложить на основе переданного XML и данных о стилях полученных из описания новой версии запроса. Чтобы не привязываться к платформе можно записывать html для печати во временную папку и открывать ассоциированным браузером. Либо выводить в самой программе псевдографикой моноширинным шрифтом как у AlcorVol) и ждать нажатия кнопки "Подписать и отправить".
После этого программа передает запрос в другую библиотеку для подписания/отправки вместе с адресом, портом, сертификатом. Как-то так, но это совсем "просто" получается.

Отправлено спустя 49 минуты 52 секунды:
Еще подумалось, что можно в библиотеке подписания просто запретить слова из юридических формул вроде "Продаю" "Дарю" "Завещаю" и возвращать ошибку, если текст их содержит.

По-моему, эта функция находится в личном кабинете на самом видном месте и называется "подключить лицевой счёт". Можно указать номер лицевого счёта и адрес, и подключиться к _чужому_ лицевому счёту, если собственник не запретил подключение.

Вот отклонение от отраслевых стандартов (я имею в виду не только ГОСТ, но и RFC и пр.) - это серьёзная проблема, и здесь я однозначно на стороне тех, кто хочет, чтобы стандарты соблюдались.
Установление новых стандартов и повышение единообразия - тоже дело хорошее, но проблема в том, что всё это требует времени, а внедрять надо уже сейчас. Так что увы, строгий порядок нас ждёт только на кладбище (квартал такой-то, ряд такой-то, могила такая-то), а пока мы живём, нам придётся бороться с беспорядком. Так этот мир устроен.

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

А написание портабельного кода - дело хоть и не невозможное, но всё же не тривиальное, и граблей на этом пути разложено значительно больше, чем хотелось бы. Тот же __stdcall - не стандарт, а расширение языка, gcc его не поймёт.

Вот про кривизну - это уже более конструктивный разговор.

Порядок аргументов, ответственность за очистку стека, передача части аргументов через регистры.

Я скромно замечу, что программированием занимаюсь как хобби с конца восьмидесятых, а профессионально с середины девяностых, и паскаля не миновал.
Проблемы с std::string и прочими не-сишными типами в том, что двоичная совместимость гарантируется только тогда, когда всё собрано одним и тем же компилятором с одними и теми же настройками. Обычно двоичную совместимость стараются сохранять в пределах мажорной версии компилятора, хотя даже из этого правила бывают исключения. И нет, конкретно в случае std::string у Вас не будет указателя на таблицу виртуальных методов, потому что эти методы не виртуальные.

__stdcall как раз и оставит нам интерфейс на голом Си. С небезопасными строками, без поддержки исключений (exceptions), с проблемами освобождения переданной памяти, с проблемами использования из языков, отличных от си-подобных.
Паскаль, насколько я понимаю, застрял в девяностых, и поэтому у него с SOAP проблемы. Но в более современных языках всё уже есть. Либо в виде внешних библиотек, либо прямо в составе языка.

Двоичное представление - отличается.

Увы, в реальности и кладбища далеко не везде упорядочены рядами и кварталами.
Да, считаю что нужна. Федеральных ГИС все больше. В принципе, меня одного хватит, только в одиночку это может затянуться надолго. А вот продавать - смысла не вижу, так как это потянет ответственность за дальнейшую поддержку. Максимум - добровольные пожертвования.Согласен. Однако, наверняка можно использовать средства, которые понимают.
Прошу простить в таком случае.Какой ужас, тогда мне вообще не ясно почему Си++ и более поздние версии так популярны. В любом случае, передавать методы как бы не обязательно, важны данные, в том же дельфи есть тип, в котором в начале длина строки (вариации тоже разные, до 8 байт на длину), потом само значение, для гарантии еще #0 в конце. Все это (и функции работы с ним) можно описать в Unit на Паскале или соответственно в заголовочном файле Си.Что ж поделать, если с безопасными такая неприятность из-за двоичной несовместимости.Что застрял, не отрицаю. Однако с SOAP в целом никаких проблем нет, есть стандартные Unit ("диалекты" Паскаля можно адаптировать, так что насобирать их не проблема). Проблемы начинаются, когда SOAP нужно подписать ЭП вообще (из-за не очень верной каконикализации в стандартных Unit (и даже в старых системных com-объектах), не совпадающей с новейшими каноникализаторами С#, использованными в ГИС), и невнятно определенной стандартом ГОСТ ЭП в частности. С отправкой на веб-сервис тоже не все гладко - модули есть, но в них нужно добавить "вкус шифрования ГОСТ". Итого - Unit, добавляющий к SOAP "вкус ГОСТ", как раз бы пригодился. Реализации этого естественно уже есть на Паскале, но, к сожалению, готового решения не нашел, ни бесплатно ни за деньги. На форумах активно обсуждались проблемы написания, но потом авторы написали и замолчали, на попытки связаться не отвечают. Естественно, можно попробовать перенести с других языков - но для этого нужно знать язык источника и тогда собственно проще писать именно на нем. А библиотека - способ не переписывать весь код с другого языка, а только интерфейсы - это проще.
С другой стороны, смены версий форматов запросов SOAP тоже сильно действуют на нервы и вынести функционал SOAP вне "основного кода" своей ИС в "модуль генерации SOAP" было бы логично. Начать с присвоения хранимым в своей ИС данным неких однозначных имен. Дальнейшие шаги по сопоставлению этих имен с тегами в запросах SOAP не потребуют изменения ИС, а простой смены настроек "модуля генерации SOAP". А вот если понадобятся передавать данные, которых нет в ИС - собственную ИС все равно придется дорабатывать: добавлять таблицы/поля для хранения данных, формы ввода и определять новые имена, но это не так сложно, по сравнению с чтением огромной, меняющейся и частично неверной документации к запросам. И снова в этом случае код "модуля генерации SOAP" менять не придется, а только его настройки. Если посмотреть шире, то "модуль генерации SOAP" будет в общих чертах одинаков практически у всех. Какой смысл тратить человеко-часы на написание его снова и снова разными разработчиками. С моей точки зрения, библиотека DLL как раз такой способ вынести общий, редко обновляемый функционал вне "основного кода" ИС.
Кроме того, если не ограничиваться ГИС ЖКХ, то, например, СМЭВ требует сохранять все запросы и ответы в базе данных (так порой сделаешь неправильный запрос, обнаружишь тестом, что в нем ошибка еще до отправки, а нет - удалять нельзя даже неотправленный запрос, так и висит как памятник глупости), а это в свою очередь пересекается с импортозамещением баз данных. То есть, по-хорошему, нужна вообще платформа включающая формирование SOAP из XML, подписание, отправку и отечественную базу данных (ясно что это уже не бесплатно, но хотелось бы за приемлемые деньги).

Отправлено спустя 26 минуты 50 секунды:
Спасибо, попробую. Логично, я эту функцию и использовал, но после выбора адреса - выдало, что у меня нет прав. Правда, номер лицевого я не указывал (и мне интересно как я должен был об этом догадаться). С этим тоже проблема - например, у нас счета одной РСО выглядят вроде "01-1089" (особенность местного разработчика ПО, "01-" это номер УО/РСО), но в квитанции банк пишет просто 1089 и реквизиты компании. У другой РСО счет вида "ЧРТ010111111", в квитанции также, но на их сайте, например, нужно вводить без букв, только цифры. Поэтому я и не стал вводить лицевой счет без дополнительной "наводки" - нужно еще догадаться/подобрать, что РСО указало в этом поле.

Я бы предложил более традиционный подход: использовать для подписания документов ноутбук, изолированный от сети и хранящийся в сейфе. Документы для подписания приносить на флешке и перед подписанием просматривать глазами ответственного человека. И ОС, и криптографический софт на ноутбук установить из доверенных источников (как минимум, не из помойки, как максимум - с сертификатом от ФСБ, и ноутбук тоже сертифицированный). Другой софт, включая антивирусы, - не устанавливать вообще.
Второй вариант - использовать для работы с ГИС ЖКХ такой сертификат электронной подписи, который позволит работать с ГИС ЖКХ, но при этом не позволит ничего продать, подарить или завещать в силу "ограничений, содержащихся в квалифицированном сертификате". Подробнее, увы, не знаю.

На самом деле эта неприятная особенность существенно снижает популярность C++, а в попытках обойти её выросли такие технологии как COM, CORBA, Google Protobuf и XML. Но если у нас для всего есть исходники (что в мире C/C++ типично), то жить можно. Зато мы выигрываем в скорости на самом разнообразном железе.

Насколько я понимаю, разработчики ГИС ЖКХ пишут на C# и совместимы в первую очередь именно с ним, а с другими средствами разработки - как повезёт. Выбор C#, может быть, и не самый идеологически верный, если смотреть с точки зрения идеологов свободного ПО, но это не самый плохой вариант. С "идеологически верными" решениями, уверяю, на практике хлопот было бы не меньше. И я думаю, что лучше для взаимодействия с ГИС ЖКХ использовать C#, чем пытаться заставить работать то же самое на паскале. А паскаль с C# можно дружить уже на локальном компе.

Это, увы, следствие agile-подхода в разработке ГИС ЖКХ. Не очень удобно, зато сравнительно быстро и сравнительно дёшево. Альтернатива этому подходу - всякие ФГУП, которые пытаются действовать "правильно", но при этом хронически не укладываются в требования, бюджет и сроки. Ну и ещё бывают life-critical systems (авиация, атом и пр), там порядка несколько больше, но зато и цена такая, что ой.

Увы, нет. У разработчиков ГИС ЖКХ нет "редко обновляемого функционала". Они пытаются строить систему на ходу и не знают, что будет завтра. Параллельно меняется и законодательство, и требования, и всякие внешние обстоятельства, и внутренние баги, и пр. И смежники наверняка свои сюрпризы подкидывают, начиная с ошибочных данных в Росреестре. Со временем, конечно, всё это утрясётся, но пока - так.

Там нужен номер лицевого счёта от ГИС ЖКХ, а не от РСО. Поскольку на внедрение ГИС ЖКХ все дружно забили, этих счетов почти ни у кого нет, и подключать нечего. Мне повезло: у моего отца несколько дней был лицевой счёт, пока его не удалили, и я успел заметить и попробовать подключиться.

Согласен с этим вариантом, если бы это было в идеальном мире, где некая госструктура написала все библиотеки и сертифицировала. С другой стороны, со стороны государства все больше контроля и нет гарантий, что и в сертифицированных программах нет "закладок". Начать можно с того, что, насколько я знаю, до сих пор не опубликован алгоритм, отличающий "слабые" ключи ГОСТ от "сильных". При этом примеры "слабых" ключей есть (как минимум тривиальный - когда зашифрованный текст равен исходному). Конечно, хорошо, что не опубликован, но хотелось бы убедится, что ключи у нас не "слабые".
А Вы упорно упоминаете "про помойку". За "платформу" в целом можно заплатить, но в разумных пределах, скажем до 20-30 тысяч за все (то есть за каждую "перепроданную" доработанную копию). За одну-две сертифицированных библиотеки для написания своей программы, которую я не собираюсь продавать - ну долларов пять максимум.

Собственно, я никого не убеждаю в использовании библиотек неизвестного происхождения, у всех своя голова на плечах и свои представления кому и чему они доверяют. Я ведь тоже не беру чужую библиотеку, а пишу свою. Если кто-то захочет ее использовать - пожалуйста, мне не жалко (еще даже не написал, а уже столько шума), если кто-то побоится - их личное дело. Даже без генерации подписи на "Продам" в интернете полно вирусов на сайтах, где можно "найти" какую-то библиотеку и вполне очевидно, что осторожность с чужим кодом (а лучше паранойя) не помешает. Так что, может быть, хватит уже напоминать "про помойку" почти в каждом сообщении - режет глаз.

Ближе к теме. При всех плюсах подхода "ноутбук в сейфе плюс ответственный человек" есть и минусы: 1) для подписания в интеграции это (перенос туда-сюда на флешке, просмотр каждого XML) не подойдет, особенно если документов много и для XML нет вида для печати - глаз человека "замылится". От "Продам" и "Дарю" это, может быть, и защитит, но от прочих ошибок - нет. А если человек сидит и просматривает, хотелось бы чтобы это несло и другую полезную нагрузку. С другой стороны, если есть вид для печати, то опять же нужна гарантия, что на экране то содержание, которое подписываешь; 2) тривиально, но не у всех размер сейфа позволит положить туда производительный ноутбук; 3) ФСБ и др. особенно не рекомендуют использовать ноутбуки - украсть ноутбук гораздо проще и там практически всегда есть функция беспроводной сети, кстати, в сертифицированных ноутбуках антенну физически отрезают (у нас один есть в "секретном" отделе - стоимость железа, программ, вместе с сертификацией где-то 120 тысяч, сертификацию периодически нужно продлять, так что для многих при упоминании стоимости вопрос сразу закрывается); 4) для организации это значит минус один сотрудник, занимающийся только подписям; 5) флешки и без антивируса - это точно идеальный мир, а не тот в котором мы живем. В сертифицированных "секретных" ноутбуках вообще запрет подключать флешки - весь обмен документами исключительно на оптических дисках, а антивирус установлен, DrWeb.
С этим я еще более согласен, я бы вообще все сертификаты сотрудников ограничивал к черту. Но с этим все гораздо хуже. Несмотря на упоминание в законе "ограничений, содержащихся в квалифицированном сертификате", фактически я еще не видел ни одного такого сертификата (имею ввиду российского, в зарубежных бывает "Заявление поставщика" - не знаю, может быть это оно и есть). Более того, работники местного отделения Федерального Казначейства, оформляющие заявки в удостоверяющий центр мне официально заявили, что нет возможности исключить использование определенного квалифицированного сертификата за пределами определенной ИС. При этом в форме заявки можно указать те самые ограничения. То есть, хотя ограничения как бы есть, нет механизма, который бы исключал их нарушение. В законе об электронной подписи тоже сказано всего лишь, что владелец должен использовать сертификат, соблюдая установленные в нем ограничения. Лично я не уверен, что этого будет достаточно для признания предложения "Продам..." юридически недействительным. Зато буквально на днях смотрел, что в новой редакции, вступившей в 2016 году, добавили, что любая государственная ИС не может предъявлять к сертификату требования, исключающие возможность использования этого сертификата в других ИС.

Не буду спорить о разнообразии железа и выигрыше у других языков высокого уровня, но вот насчет выигрыша Си, скажем у ассемблера есть сомнения. Даже на x86 у разных процессоров есть различия в скорости выполнения тех же инструкций и многое зависит от того как компилятор переведет язык высокого уровня в машинный код. Вроде как общепринято, что из-за этого ассемблер дает до 40% прироста скорости?
Пожалуйста, поясните, как тут мысль перекинулась на XML? Имеются ввиду манифесты?
Лично я даже и не рассматривал с точки зрения свободного ПО, но соглашусь. Для меня проблема не в идеологической верности, а в том что для меня C# это синоним dotNet Framework. Поправьте меня как более сведущий в мире языков Си, если я не прав. Я категорически против таких огромных фреймворков и именно поэтому лет надцать не стал переходить на C#, хотя выглядело чертовски заманчиво. С библиотекой Visual Basic в те времена можно было смириться - она практически везде ставилась с Windows. Но dotNet меня не устраивает - 1) огромный, даже хотя он у меня уже стоит и обновляется, когда вижу в системных требованиях, стараюсь выбрать альтернативное программное решение; 2) постоянно находят ошибки, что можно выполнить произвольную программу с админскими правами; 3) не менее постоянно обновляется, чтобы их закрыть - и после этого не знаешь, а запустится программа или нет; 4) программы требующие его, нужно обязательно устанавливать штатным установщиком, просто распаковать EXE c библиотеками и запустить не получается - выдает кучу ругани на зависимости компонентов, даже если dotNet стоит; 5) серьезно, сообщения об ошибках выглядят как невразумительная ругань, при том не связанная с самой ошибкой. Было большим открытием когда "матерился" на тип integer в веб-клиенте Росстата и исправилось установкой обновления; 6) и вот только после этого идет, что идеологически неверен. В итоге, дружить свое решение с C# смысла не вижу, так как это не уберет зависимости комплекса от dotNet. Поэтому уж лучше "изобрету велосипед", но без dotNet-зависимости. Уверен очень многие разработчики, не использующие C#, будут солидарны со мной.
С этим соглашусь в целом.
Это не полностью верно, мы же не они. У них нет, а у нас может быть. Просто нужно, чтобы все изменения можно было "решить" не изменяя исполняемого кода. Скажем, обменяться настройками. Тут все зависит от того, как выстроить абстракцию.
Простой пример, понятный каждому программисту: если меняются требования к Вашей программе, Вы корректируете исходники, а не обновляете транслятор/компилятор! В этом случае, можно считать правила формирования машинного кода под конкретную архитектуру - стандартом, компилятор - редко обновляемым функционалом, а исходники Вашей программы и передаваемые опции - своего рода "настройками" для него. То есть берете "настройки" (исходник), отдаете "редко обновляемому функционалу" (компилятору), получаете "продукт" (исполняемый файл) соответствующий "стандарту" (правилам формирования машинного кода). Важно взять за "стандарт" что-то такое, чего разработчики не собираются менять. Ну вот вообще не собираются.
Применительно к интеграции с ГИС ЖКХ логично взять за "стандарт" описание протокола SOAP, за рамки которого разработчики не собираются слишком сильно выходить. Если 1) сделать полную реализацию всех его возможных деталей в "модуле генерации SOAP" ; 2) в "настройках" по факту указать какие именно детали реализации и как использовать плюс какой шаблон использовать, тогда "настройки" (плюс данные) можно воспринимать как своего рода исходник, а "модуль генерации SOAP" как своего рода транслятор, а готовый запрос SOAP как продукт трансляции. Все счастливы, а модуль генерации можно не обновлять. Конечно, как все "универсальное" (реализующее все возможные детали и анализирующее "настройки" при выполнении) это будет работать гораздо медленее, чем "специализированное" под конкретные детали, используемые конкретной ГИС на текущий момент. Другой вопрос, если разработчики вдруг захотят добавить нечто не предусмотренное протоколом. Или расширят стандарт так, как мы не предусмотрели. Тогда да, придется модуль изменять. Поэтому важно заранее хорошо придумать как такие расширения отразить в настройках, когда они внезапно появятся.
Шутите? Повезло? Если так, то о каком добавлении своих/чужих счетов можно говорить. Подбирать ЕЛС никто не будет и в квитанции ЕЛС пока не фигурирует. Еще вариант прийти в УК/РСО лично и между сверкой платежей выспросить/подсмотреть. А значит на этом можно пока поставить точку - без знания ЕЛС сможет подключить только "собственник". А значит внесенные сведения практически никто не увидит. А значит "большинству населения" толку ноль от ГИС - вроде все полезно, а доступа нет.

Да господь с Вами. В первый раз упомянул.

В принципе можно и бесплатный openssl взять: хоть к нему и есть вопросы, я совсем не уверен, что решения с сертификатом от ФСБ будут лучше.

Я в основном о том, чтобы не использовать ЭЦП на том же компе, на котором внук ген. директора по ночам режется в пиратские игры. Всё, что сверх этого (сертификаты ФСБ, отрезание антенн и пр.) - уместно лишь тогда, когда есть что защищать. Если у нас ТСЖ на десять квартир, то нет смысла тратить сотни тысяч на безопасность: ущерб от взлома будет меньше.

Увы, увы. Насколько я понимаю, нынешняя политика ведомств в области ЭЦП сводится к выжиманию денег за сертификаты "для работы с площадкой Росраспилрегулирование", а о том, чтобы получить денег за что-то полезное, они даже не думают.

Так, да что такое, в третий раз браузер завис при написании ответа. Отправлю пустое сообщение с цитатами, потом добью текст по частям.Согласен. Уже есть сертифицированные решения, основанные на ветке OpenSSL (МагПро крипто пакет, кажется). То есть сертификация вряд ли означает отсутствие всех уязвимостей, скорее проверялся алгоритм формирования ключа ГОСТ и что с ключом не производится "левых" операций. При этом такая сертифицированная версия OpenSSL уже не бесплатна. Это что касается криптографических операций и подписи cades.
Тут наверно нужно еще сказать, что вызов самого исполняемого файла OpenSSL из программы выглядит как минимум не эстетично, то есть более интересно использовать ssleay32.dll и libeay32.dll. Другой довод в эту пользу - антивирусы крайне отрицательно относятся к программам, которые одновременно обращаются к интернету и запускают некий исполняемый файл - это классифицируется как неопознанный троян. У меня был такой прецедент (вызывал winrar.exe для подсчета CRC32, потом отправлял другому экземпляру программы и DrWeb определил программу как троян. Пришлось переписать на использование zlib.dll), и мне больше не хочется объяснять кому-то, что моя программа на самом деле не вирус. (Самое смешное, что программа администрирования, которая на самом деле аналогична трояну - выполняет произвольную команду полученную по локальной сети - антивирусами не блокировалась.)
У нас же задача немного сложнее - подписать XML другим определенным форматом xades-bes и включить подпись в файл. Как я понимаю, OpenSSL "из коробки" этого не умеет - иначе бы зачем изобретали велосипед в тех проектах на хабре. Так что в этом отношении все равно придется реализовать каноникализацию и допиливать формирование ЭП.
Далее, шифрование канала - тут огромное количество средств, начиная от Stunnel на основе OpenSSL (у криптопро своя версия одноименной программы, основана ли на OpenSSL до конца не ясно) до Континент-АП и Vipnet. В общем случае, почти никак не затрагивает нашу программу - меняется только адрес/порт назначения.
А вот с реализацией протокола TLS совсем плохо, несмотря на все уязвимости, OpenSSL тут мало что можно противопоставить. Конечно, есть Континент TLS клиент и Jinn-клиент (рекомендованные для ГИИС "Электронный бюджет"), но можно сказать, что они очень большая редкость. Есть компонент TLS в КриптоПро, но мне пока не очень понятно как его использовать и не понадобится ли отдельная лицензия.
Итого, если не обращать внимание на уязвимости, OpenSSL действительно практически идеальный выбор - допилить xades-bes и вперед.
Согласен. И не только внук. Порой с виду приличные сотрудники такое устанавливают на своих рабочих местах, что пиратские игры отдыхают. Как минимум будет полезно ограничить права пользователя на таком компьютере.