Форум

[QUOTE]Sergey_P пишет:
думаю все банальнее, 11-я версия более менее совпала с переделкой базы РР и им нынче несколько не до ГИСа.[/QUOTE]Согласен. Для подгрузки данных нужен определенный формат обмена. Если Росреестр изменил его (судя по сбоям в январе наверняка изменил) и старая версия теперь не поддерживается, то пока новый формат "не устаканится" и ГИС его не реализует подгрузки не будет. При этом формат устанавливает Росреестр и только затем ГИС его поддерживает. Если Росреестр удалил страницы выгрузки старого формата и не поставил редиректа на новый формат, то сбой также регистрироваться не будет. Точнее на веб-сервере регистрируется, что кто-то запросил старую страницу и сервер ответил "404 Not Found", но в АИС Росреестра это наверняка не идет.

В принципе такое изменение можно сделать не меняя глобально версию ГИС, но видимо есть какая-то система контроля версий не позволяющая сделать "по-крестьянски". Значит ждем-с.

[QUOTE]Зануда пишет:
 работаю в нем через личный кабинет со своей ЕСИА по коду отправленному на мой телефон[/QUOTE]Замечательно, значит никто другой не войдет. Ну если телефон не свиснут.[QUOTE]Зануда пишет:
как ограничить мои полномочия с 28 числа?[/QUOTE]В ЕСИА удалить себя из групп администраторы ГИС ЖКХ и пользователи ГИС ЖКХ. После удаления из групп доступа пользовательское соглашение будет аннулировано.
Однако при этом у нового директора будут сложности с добавлением полномочий - как уже обсуждали некоторые полномочия может назначить только старый директор (после прикрепления нового по его ЭП) или придется долго стучать в техподдержку. В связи со спецификой - чтобы новый директор прикрепился ему нужна электронная подпись и запись в ЕГРЮЛ, а их не сделают пока не вступит в должность. Конечно можно попробовать пригласить заранее его (как сотрудника), назначить права, а уже потом пусть прикрепляется по ЭП и становится руководителем, но скорее всего не выйдет. Другими словами если решите передать "по-хорошему" и только потом все связи снять, то полномочия придется сохранить энное количество дней после вступления нового директора. Если это нежелательно - просто уберите себя из групп.

Если включены еще в какие-то группы, то из них тоже можно выйти. Далее уже открепиться от УК - так как электронная подпись закончилась, то это будет необратимо, прикрепиться как руководитель обратно уже не сможете. Если ни для чего другого электронную подпись не используете, можно еще и запретить вход по электронной подписи, чтобы ни у кого не было соблазна сделать ЭП на Вас пока ЕГРЮЛ не изменен и зайти от Вашего имени (насколько помню при входе по ЭП может и не прийти смс).

[quote:3748hbi5]Господа, а кто-нибудь задумывался о том, чтобы у себя в УК сделать ЕДИНУЮ базу данных, автоматизирующую заполнение шаблонов?
Берем весь набор шаблонов, по ним составляем свою БД, привязываем поля БД к полям шаблонов... Внесли один раз - раскидало по шаблонам - грузим шаблоны.[/quote:3748hbi5]Вау, программистский подход! ;) Я собираюсь сделать нечто подобное, но для SOAP шаблонов в рамках модуля обмена настройками и модуля генерации SOAP. Но это отдельный разговор, все еще на стадии теоретического обоснования.

Эксель же явно собьет данные при прямом запросе данных в шаблон (перезапишет форматы ячеек на полученные из БД). Как вариант можно попробовать получать данные запроса не напрямую в шаблон, а в соседний экселевский файл и уже оттуда аккуратно копипастить макросами с соблюдением форматов шаблона. Макросы естественно тоже в соседнем файле, чтобы ничего лишнего в шаблоне не оставалось.

Добавлю, что отдельный разговор о совершенно неоптимальных форматах полей, выбранных в шаблонах ГИС.  На Экселе это может быть и незаметно, а в чате программистов SOAP вовсю матерят форматы полей: бывает, что для более точной величины оставлено меньше знаков чем для менее точной или с одним знаком после запятой и с 4 знаками после запятой значение принимается, но с 2-3 знаками после запятой ну просто ни в какую. Вот вам и программирование на dotNet - регулярно всплывают глюки преобразования форматов. Поэтому перебивать свою базу под форматы ГИС совершенно не вариант - они то потом добавят количество знаков после запятой, а нам мучаться с потерянной точностью. Вывод: формат должен подгоняться под текущие капризы ГИС уже при заполнении.

[QUOTE]Ale][ пишет:
Работает как часы, но тут грянул SOAP... его думаю реализовывать на C#[/QUOTE]Я как раз-таки хочу прийти к dll (на основе Pascal) в работе с SOAP. Все же считаете, что много недостатков у использования dll и отдельное приложение более оправдано? У Вас уже и xml схема используется и процедура выгрузки есть. Глобально нужно - зарегистрировать ИС, настроить stunnel, освоить подписание и соединяться со stunnel. Ну и шаблоны изменять по мере необходимости.
Основная проблема все же в приведении к каноническому виду, а сами значения хешей/подписи получить можно различными путями, склеить их в XML-DSIG тоже вполне решаемо. Как тут уже говорилось, каконикализацию можно пропустить, если будет заложен шаблон уже приведенный (вручную, например) к каноническому виду, однако если автоматизированно брать предложенные авторами ГИС шаблоны при обновлении версии ГИС, то не факт, что шаблоны будут каноническими и без приведения не обойтись.
[QUOTE]AlcorVol пишет:
сейчас совсем другие текущие задачи навалились, с ГИСом никак не связанные. С ними и ковыряюсь...[/QUOTE]Ясненько. Новый год - новые задачи. :D

[QUOTE]AlcorVol пишет:
Сочувствую![/QUOTE]Солидарен.[QUOTE]AlcorVol пишет:
 Разгребаю уже месяца два, но конца пока не видать.[/QUOTE]С октября-ноября вроде бы это обсуждаем, а уже середина марта.[QUOTE]Ale][ пишет:
Меня поставили в разработку интеграции. Изучаю её уже часа 2... Прочитал данную тему от начала до конца, вопросов стало еще больше, чем было.[/QUOTE]2 часа... "Все еще только начинается"(с). Часть ссылок и информации есть и в соседних темах. Немного неудобно, но у нас модераторских прав нет (без них даже собственные старые сообщения не отредактировать) и потому информация получается "размазана" по темам. Вопросы задавайте, может быть что-то проясним. Вопросы по отдельным шаблонам XLS лучше задать в соответствующих темах "Форум по ГИС ЖКХ", а по разработке - здесь. В свою очередь, хотелось бы узнать на каком языке планируете писать интеграцию.
Пожалуй нужно описать все более подробно и структурировано, начиная с терминологии по электронным подписям и не отвлекаясь на другие темы. Как дойдут руки, хочу оформить все накопленное из разных источников в виде цикла статей (с рабочими фрагментами исходников). Есть множество хороших статей, но не учитывающих ГОСТ и множество средненьких, но с ГОСТ, поэтому все же придется по мере сил дополнять особенностями ГОСТ, а не просто давать ссылки.

Правительство 28 февраля внесло в Госдуму проект [URL=http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=111753-7]111753-7[/URL] по изменениям в законы по ГИС ГМП. Если вкратце - 1) хотят перевести на Правительство полномочия по определению какие "иные платежи" нужно вносить в ГИС ГМП; 2) ужесточить сроки внесения начислений и информации о платежах с "незамедлительно" до "незамедлительно, но не позднее дня приема (начисления)"(+фиксировать дату внесения+наказывать за нарушение сроков); 3) ввести фиксацию доступности ГИС ГМП.

Первое - давно пора. Второе похоже сравняет ГИС ГМП с ГИС ЖКХ и данные банкам придется отправлять без гарантии доставки. А ведь тоже были уступки с учетом касс без Интернета и прочего. Сомнительно, что к 1 января 2018 касс без Интернета не станет. Видимо, в таких кассах просто прекратят принимать перечисленные Правительством платежи.

Третье вызывает серьезные технические сомнения. В СМЭВ, откуда норму переносят, уже есть сервисы, в которых разделены всегда доступный сервис и реальная ИС, временами недоступная из своего сервиса. При сбое связи между ИС и сервисом на рабочие данные возвращается ошибка связи, но при этом сервис бодро рапортует о работоспособности на тест доступности.Такими темпами и до ГИС ЖКХ внесение платежек в тот же день может дойти. Вообще будет "замечательно", если в кассах без интеграции с ГИС перестанут принимать платежи.

P.S. По другому поводу полазил в настройках ГИС (гениальные разработчики добавили в данные организации процент участия органа ОМСУ - особенно смешно смотрится для самого органа ОМСУ), обнаружил возможность вкл/выкл автоматическое квитирование.

Из опыта - если информация была введена и "пропала", то бывает через некоторое время "возвращается" - в ГИС постоянно вносятся поправки и информация временно выпадает из просмотра. Потом техподдержка что-то делает и информация отыскивается. Можно конечно бомбардировать запросами техподдержку, но честно не вижу видимого эффекта. Кто-то еще позвонит и исправят всем.
Не поддавайтесь панике сразу же как обнаружите "недостачу", поберегите нервы, но держите на заметке - если за месяц-два не объявится придется штурмовать техподдержку или снова вносить.

Все верно. Я имел ввиду конечно не договор между УК и РСО (извините, если ввел в заблуждение), а договор с жителями (в одном случае это договор управления - для УК, в другом договор ресурсоснабжения - жителей и РСО), без которого не дает внести ПУ.

[URL=http://forum.burmistr.ru/viewtopic.php?f=133&t=5097]Навскидку тема с Вашими сообщениями.[/URL] Хотя возможно устарела. По ней выходит что: либо отмечаете в договоре управления, что предоставляете КУ (которых в данном случае УК не предоставляет! то есть неправда) и вносите ПУ по нему, либо ждете ресурсников пока они по договору ресурсоснабжения внесут ПУ.

[QUOTE]Sergey_P пишет:
А вот зачем это вам - не понятно. )[/QUOTE]Так-то конечно так, но тут уже не раз говорилось, что данные разных организаций пересекаются и зависят друг от друга. Если кто-то один ничего не вносит, то остальным участникам ГИС придется занести эти "пересекающиеся" данные самостоятельно, то есть объем их работы увеличится.

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

Действительно, подозрительно. Ну, у всех немного разные схемы. Если УК вообще никак КУ не потребляет (важно установить так ли это, тут встречались и УК, которые газом или отоплением воду греют - там сложнее), то полагаю, договоры и не нужно размещать.
Максимум - позвонить ресурсникам и намекнуть, что пора бы уже зарегистрироваться и начать заполнять информацию. Хотя догадываюсь, что они ответят.

Пожалуйста, спасибо за упражнения для разминки ума.
[QUOTE]Programmer пишет:
 его имя модифицировать при обнаружении во входящей папке, используя часы сервера.[/QUOTE]Да, лучше использовать часы сервера. В принципе не обязательно модифицировать имя файла - вместо папки отработанных еще лучше будет сохранять время обработки (по серверу) в базе данных. К Delphi прекрасно подходит Interbase/Firebird базы данных, к PHP (об этом ниже) подойдет mysql(обычно быстрее, включена в xampp) или odbc (версия на основе Microsoft Access файла включена в MS Office, если его нет можно скачать MDAC (Microsoft Data Access Components) отдельно, тут меньше закидонов при написании запросов чем в mysql).

Сохраненные времена сервера, номер  клиента, месяц/год запрашиваемых данных можно использовать как журнал - кто, что и сколько раз запрашивал. Соответственно ограничивать "ретивых" более гибкими условиями - например, обрабатываются запросы без интервалов по времени, но не более 10 за последний час или 100 за месяц. Или игнорировать и удалять запрос если сочетание месяц/год недавно запрашивалось.
[spoil:1yxt1t77]Естественно по почте без интервала отправлять немного рискованно, но если ли за одну обработку нашлось несколько запросов от одного клиента, то их все можно зацепить к одному письму. А на следующую обработку уже применять интервал игнорирования в 5 минут, пройдет 5 минут зацепить остальные (если по количественным ограничениям проходят, а если не проходят, то либо игнорировать пока количественное ограничение не сработает либо удалять).[/spoil:1yxt1t77]
[QUOTE]Programmer пишет:
Время обработки определяется только по имени файла, но клиент этот файл не видит, так как содержимое будущего файла записывается в строку (память), а потом строка сохраняется, как файл непосредственно на FTP.[/QUOTE]В этом случае возможно еще удобнее будет отправлять http запрос вместо файла. [spoil:1yxt1t77]Из описания схемы было неясно запрашивается ли пароль на FTP, но если запрашивается и у все одинаков - это тоже потенциальная дыра в безопасности. С другой стороны, я избегаю использовать IIS (может это предубеждение, но раньше в нем было столько дыр безопасности, что до сих пор ему не доверяю). Тут дело еще в том, что практически в любом пакете совмещающем http и прием файлов (по http или ftp в том числе) есть риск безопасности при загрузке файлов в доступное через http место.
Плюс http в том, что тогда можно сразу клиенту ответить, что запрос игнорируется из-за слишком частых запросов. Кроме того, можно динамически изменять различные секретные коды. То есть использовать номер клиента первый раз чтобы получить код, потом код можно потом использовать как (одноразовую?)замену паролю и номеру клиента. Если код не подошел то использовать номер клиента еще раз.[/spoil:1yxt1t77]
В принципе, можно вообще уйти от прошивки данных в программу (пришел собственник, его email "оператор" зарегистрировал, при регистрации сразу высылать программку)[spoil:1yxt1t77]При отсутствии файла конфигурации (первом запуске) спрашивать почту, которую собственник сообщил УК при получении программки и соответственно записывать в файл конфигурации 2 email (изначальный вместо номера клиента и последний введенный - для получения данных на него) и запросить по http проверку изначального email от сервера. На стороне сервера искать по базе данных изначальный email и получать номер клиента. Если нашелся - возвращать программке сгенерированный одноразовый код (код, номер клиента и время его выдачи сохранять в базе сервера в отдельной таблице), если не нашелся - возвращать программке ошибку, о чем программка выдаст сообщение "Email не зарегистрирован" собственнику .
При запросе данных - указывать одноразовый код, месяц/год запрашиваемых данных и новый email, данные можно передать в теле POST запроса. На сервере искать код и по нему определять номер клиента и время выдачи кода. Если не нашелся или истек - выдавать ошибку, по которой программка снова проверит изначальный email и получит новый код, потом повторит запрос данных. Если нашелся - сгенерируем, сохраняем, выдаем в ответ новый одноразовый код, старый код удаляем из таблицы, затем передаем запрос на исполнение или сохраняем в файл как раньше.
Минус - придется написать скрипт на PHP (тут можно скачать пакет xampp portable с уже настроенным совмещением PHP и Apache и наконец заглушить IIS чтобы не создавал дыр). Из PHP можно запускать переделанную на параметры командной строки вместо имен файлов "старую" программку (тогда станет недоступным совмещение нескольких запросов в 1 письмо нескольких запросов) или как ранее сохранять файлы из PHP в недоступную по http  папку для обработки программкой по таймеру.[/spoil:1yxt1t77]
[QUOTE]Programmer пишет:
Таким образом, некоторая защита от профанов имеется, а "волкам", которые это взломают будет жаль потраченного времени.[/QUOTE]Я придерживаюсь такого же мнения, что от направленного взлома специалистом ("волком") мало что поможет. Такой не только программку раскрутит на винтики, но и сервер запросто возьмет под контроль через уязвимости IIS.
С другой стороны, дополнительно затруднить взлом "профанам" не помешает. Не так уж и сложно перенести критичные операции на сторону сервера.[QUOTE]Programmer пишет:
У меня есть карта СБ РФ. Если я попробую "оплатить" какую-либо услугу своего соседа (и не только) из своего личного кабинета на сбербанк-онлайн, то я могу узнать о его долгах за эту услугу.[/QUOTE]Это везде у нас такая "секретность", на уровне защиты от профанов, которые этого не пробовали сделать, не удивительно.

Даже не знаю что сказать.. Уж простите, что первые мысли "как сломать систему"..  :lol:  Если время прошлой обработки определяется только по имени файла, то у меня пожалуй выйдет запросить с такой прогой где-то 30-40 квитанций за час) можно переименовать файлы так что бы казалось что между ними 5 минут и несколько секунд ~30 шт.(или поиграться с часами компьютера) и закинуть с интервалом 2 минуты. Пока закидывается пройдет еще час ~10 штук. Именно поэтому обычно подробности об интервалах хранят в секрете.
Про "персональный" номер собственника вообще ужас - про ArtMoney знает почти каждый "игроман".  :o  Продвинутый в части пользования компьютером собственник на раз найдет нескрытый номер в памяти программки и поменяет его на нужный. [URL=http://help4game.ru/articles/secret/luchshie_programmy_dlja_vzloma_i_chitinga­_v_igrax.html]Подробнее[/URL]. А если скрывать (шифровать например), то прошивка скорее всего испортит данные.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 15 минуты 8 секунды:[/COLOR][/SIZE]
Вообще, честно говоря, Delphi один из наименее защищенных от обратного инжиниринга компиляторов, так как давненько не обновляется и все стандартные библиотеки уже есть базах программ дизассемблирования (например IDA Freeware). За полчаса можно отсеять код из стандартных модулей и полностью восстановить исходник небольшой программки поэтому лицензии, ключи и т.д. остаются практически без защиты, даже если их зашифровать (ну разве что от Denuva будет толк). Впрочем, с Си и Си++ аналогичная ситуация, так что это не наезд на Delphi, а просто предостережение, что критичные и персональные данные нужно защищать отдельно.
К слову, попадались на глаза программки местного авторства, где лицензия проверяется во внешней библиотеке. Это вообще не выдерживает критики - даже не нужно программу разбирать, достаточно просто заменить библиотеку.

В продолжение темы поддержки длинных строк. Сделал все-таки гибридный тип - принцип примерно как у ansistring, но с дополнительными "фишками": хранятся актуальная длина данных строки, длина выделенной памяти, признак фиксирования и указатель на собственно выделенную память.
Плюсы: можно передавать в параметры (размер самого типа 16 байт, стек не забивает), размер автоматически увеличивается при необходимости (при этом выделяется новый буфер, данные копируются, старый буфер освобождается; максимальный размер для увеличения пока переехал из прошлой версии длинных строк - 20 МБ), размер можно задать вручную (правда если задать больше 20 МБ при обращении к памяти срабатывает исключение Range Check, вероятно надо будет увеличить описание типа-указателя до пары гигабайт).По умолчанию после данных еще и #0 записывается (но не считается в актуальную длину данных строки), то есть данные в буфере совместимы с PChar.

Гибридность проявляется в том, что можно установить признак фиксирования и при этом отключится изменение размера строки и "перепрыгивание" адреса буфера. При этом все "не вошедшие" в выделенную память символы будут отбрасываться как в обычном shortstring. Использовать можно по-разному: выделить 20 МБ, зафиксировать и использовать в вызовах WinApi, не опасаясь, что строка "перепрыгнет" на другой адрес после изменения одного символа как у ansistring. Или зафиксировать и вручную установить указатель на любой буфер, в том числе не динамический - так удобно хранить данные при вызовах WinApi, чтобы не объявлять кучу переменных.

Минус тоже выискался - у ansistring работа с указателем буфера прописана отдельно в исходнике компилятора, а у гибридного типа нет. Значит невозможно переопределить оператор присваивания одной гибридной строки другой - компилятор тупо копирует содержимое записи, в том числе затирая ссылку на буфер без освобождения буфера; вместо того чтобы скопировать данные в буфере в другой буфер.
Так что с присваиванием все также торчат уши в виде lstr_Assign. От присваиванию указателю правда избавился, но теперь желательно вызвать lstr_New для корректного выделения буфера, так как заранее не известно какой мусор попадет в начальное состояние переменной при размещении в стеке.
В общем избавился от фиксированных типов разной длины в пользу типа с переменной длиной - сразу стало легче писать. И с памятью должно быть экономичнее.

Функции связанные с криптоядрами попробовал объединить в отдельный класс, но пока непонятно что получается. Как выяснилось при запросе контекста КриптоПро выдает окно вставки носителя, буду еще разбираться что и как. Среди прочих материалов откопал исходник универсальной функции - в зависимости от параметров она возвращает хэш или подпись или сертификат или открытый ключ. Все в виде стримов. Для моего структурирования классов не подойдет, но вообще изящное решение. Понемногу выстраивается как использовать Криптопро и OpenSSL для аналогичных операций.

[quote:3r4901bo]Пока не знаю, но в кратчайший срок разберусь. Хочу возобновить работу с смс - шлюзом.[/quote:3r4901bo]Интересно узнать результат. Может быть за прошедшее время что-то еще удобнее придумали. На ум приходят всякие месенджеры, которые часто умеют отправлять смс.
По сегодняшним временам 28 копеек за смс несколько дороговато, в большом тарифном пакете выйдет по 10 копеек или даже меньше.
[quote:3r4901bo]Да-да. Именно так. Всегда ценю иронию. И сам тоже умею и люблю быть чуточку (ну, совсем немножечко!) язвительным.[/quote:3r4901bo]Рад что понимаем друг друга, а то бывает посмеюсь как бы над самим собой, а люди обижаются.

[QUOTE]AlcorVol пишет:
Ну, и на mail.ru мне тоже пришлось завести специальный "служебный" аккаунт. От его имени и посылаю всё.[/QUOTE]Теоретически, если есть свой домен и почтовый сервер на статическом айпи (желательно чтобы другой почты через него не шло), можно настроить в DNS домена TXT SPF запись с правилами почты и явно разрешить там этот сервер (и запретить все остальное).
Другие сервера проверяют правила для домена отправителя и если письмо соответствует правилам - это плюсик при выборе принять ли письмо; если не соответствует, то отклоняют; если правил не задано, то на их усмотрение. Так можно обойтись и без служебного аккаунта вообще, но конечно проще использовать специализированные сервисы.[QUOTE]AlcorVol пишет:
посылает только явно, по запросу "оператора"[/QUOTE]Ясненько, то есть примерно как на некоторых сайтах: ввели показания счетчика и рядом кнопочки "скачать счет", "получить счет на почту". Только вместо сайта и кнопочки - телефон и бухгалтер.[QUOTE]AlcorVol пишет:
С ума сойти! Нашлась-таки такая область, где ты не очень хорошо разбираешься.  Но я-то - ещё меньше![/QUOTE]Увы и ах! Конечное существо не может постичь бесконечный смысл! Даже если ограничится программированием и не брать в расчет устройство современного автомобиля, модуляцию сигнала в локальной сети и принципы работы полевого транзистора все равно это слишком много для одного человека. Еще области - распознавание речи, лиц, алгоритмы сжатия медиафайлов, искусственный интеллект, веб-программирование фронтэнда (я хоть и пишу странички, но все по старинке без фреймворков, промисов и прочего - по идее можно раз в год переписывать абсолютно все страницы если держаться новейших технологий), моделирование погоды, параллельные вычисления, криптовалюты, разработка игр наконец (оно кажется просто, но после того как мне показали гигабайт учебников по разработке игр я призадумался). Короче даже не нужно особо напрягаться для поиска областей, где узкий специалист переплюнет универсала.[QUOTE]Programmer пишет:
Помню только что я из программы (пресловутая Delphi) вызывал GET запрос, в котором указывал свой ID, полученный при регистрации, в ответ на это приходил еще какой-то код, (каждый раз - разный) который надо было отправить обратно с текстом сообщения.[/QUOTE]Принцип понял, что-то вроде OAUTH - для списывания со счета (запрос доступа - изначально присвоили код для лицевого счета; первый запрос - запрос access_token; второй - операция). Такая технология сейчас используется при публикации плагинов Мозиллы, в приложениях vkontakte и при доступе к данным пользователей ЕСИА. Читать читал, но пока не работал. Сейчас эта схема уже не работает?

[quote:1t0ubau2]Не успеешь глазом моргнуть как наступит ответственность...[/quote:1t0ubau2]Спасибо. Классный текст сообщения, однако. Судя по тому, что я вижу в папке synapse... там уже половина исходников для соап есть. DLL ки правда 10+ летней давности. А еще по названию синапс припомнился фильм "Опасная правда".
[QUOTE]AlcorVol пишет:
FoxPro позволяет вызывать командой RUN любые консольные приложения.[/QUOTE]На PHP принцип такой же и куча консольных программ отправки, правда большинство для Linux. Еще я как-то пробовал отправлять через Яндекс себе от своего домена, на котором не установлено ограничений с каких адресов почта допустима через программу Kerio Mail Server. Обычно Яндекс без своей авторизации от клиента письма не принимает. Как ни удивительно, оказалось что если другой почтовый [B]сервер[/B] в заголовках письма пишет "авторизация пройдена, зуб даю", Яндекс дает отправить через себя 1 письмо в 15 минут с левым адресом. Естественно если авторизоваться нормально, то можно побольше и почаще, но только от своих адресов.
А поводу ограничения спама есть какие-то задумки? Допустим, прикручу отправку письма (или смс) к добавлению заявки на сайте, но это же будет ужас если на каждую заявку письмо. Думал сделать планировщиком (раз в 3 часа, например) проверять есть ли заявки и высылать письмо, но так потеряется оперативность первой заявки (допустим в 9-05 отработает и ничего не обнаружит, а кто-то заявку сделает в 9-06 и три часа провисит).
К слову, отправка смс, Android и мобильные приложения - пример области, в которой я только смутно разбираюсь - что наверно надо что-то как-то отправить на смс-шлюз, но без понятия что, как и где шлюз брать, с Ростелекомом договариваться наверно? и что можно мобильное приложение самому написать и скидывать на телефон вручную, не через магазин. Все. Наверно еще можно установить дешевый тарифный план на телефон, подключить к компьютеру и отправлять смс через телефон, но как это сделать программно - не в курсе.

Спасибо большое за лестный отзыв. Сам себя к асам наверно относить не  стану, хватаю всего помаленьку, но постепенно кое-что накапливается. За неполных 20 лет программирования еще ни одной крупной программы, зато куча мелких или одноразовых. На наш отдел сваливают все что что хоть как-то с компьютерами связано, за месяц более 100-200 разных обращений от мелких "мышка не бегает", "картридж нужно заправить", перезагрузить 1С, опубликовать новость на сайте, переустановить Windows до таких необъятных как взаимодействие по соап с разными ФГИС. С ЭП впервые столкнулся лет 6 назад, наблюдал за действиями коллеги. 3 года как занимаюсь ЭП вплотную. Openssl, разбор сертификатов на байты, собственный УЦ на openssl уже около года в работе, а соап и ГИС месяца 4. Короче интересов много, на все времени не хватает, тем более что очень часто отвлекают не по делу, весь январь доставали с отчетами.
Из февральского - в 2005 и 2015 году были приняты законы по концессионных соглашениям в сфере ЖКХ, в начале февраля внезапно в ГАС "Управление" сделали возможность заполнения информации по ним и дали сроку до... 22 февраля. Прям зло берет - сами делали пару лет, а нам дали 20 дней. Причем возможность загружать xls файлы включили за 5 дней до срока. Пришлось все бросать и набивать вручную данные, о которых мы вообще как-то без понятия - реальные или красивая сказка на бумаге. На получение реальных нужно немало времени, так что скорее второе.В свою очередь мне было бы интересно узнать про SMS (для внутреннего сайта приема обращений от коллег) и почту (теоретические наметки есть, даже свой мини клиент-сервер POP3 когда-то писал, больше интересно как не спамить сообщениями и про вложения).

[SIZE=85px][COLOR=greenpt]Отправлено спустя 19 минуты 3 секунды:[/COLOR][/SIZE]
Очень надеюсь, что все же доведем совместными усилиями СОАП до ума. Пока для себя все представляю в том же ключе - модуль генерации соап, модуль подписания XML-DSIGN, модуль отправки, модуль обмена настроек генерации через сайт, модуль анализа шаблонов, типовой сайт обмена настроек. Естественно, еще куча "подмодулей" и возможность выбора криптоядра. Про обмен настройками я тут подробно еще не расписывал, но есть "альфа версия" описания в Word.
Возможно, имеет смысл вообще начать осваивать git и создать проект на github для совместной работы. Если конечно коллеги согласятся объединить усилия хотя средства разработки у всех отличаются. На форуме выкладывать несколько неудобно, но очевидно, что чем больше глаз будет наблюдать, тем проще выловить потенциальные ошибки и улучшить код.

[QUOTE]Дамир пишет:
Пользователю телевизора не нужно знание принципа работы полевого транзистора.[/QUOTE]Дописал про WebDAV - там даже отдельную программу не надо. Настроил stunnel (можно собрать архивчик, достающий ключ из системы, останется только сертификат воткнуть и его прописать), подключил сетевой диск и вперед.

[QUOTE]Programmer пишет:
Надо, например,отправить почтой файл abc.xlsx[/QUOTE]Насчет конкретно почты идея не очень удачная. Я как-то разбирался можно ли отправлять данные между подразделениями с ЭП и оказалось не так все просто.
1) По идее как канал шифруется так надо будет и отправляемые почтой файлы зашифровать. Просто шифрование канала от клиента до сервера не решит проблему, так как обычная почта соединяется со своим сервером, а не с Гисовским и тогда данные будут не зашищены между серверами. Либо надо создавать каждому пользователю учетку на гисовском почтовом сервере - тогда шифрования канала достаточно.
Шифрование файлов (как и подписание) можно сделать какой-то программой (консольной командой openssl или КриптоАрм) до отправки либо самим почтовым клиентом.
Если шифровать почтовыми клиентами, то там в сертификате ЭП должны быть строго определенные поля - назначение сертификата keyUsage (цифровая подпись, шифрование данных) и расширенное использование ключа extended key Usage(Защита электронной почты) плюс к тому адрес почты в сертификате должен совпадать с адресом с которым отправляется почта. А если шифровать по ГОСТ, то нужно еще поле "возможности SMIME" с указанием алгоритма ГОСТ. Про наличие криптопровайдера не говорю - почтовые программы в основном поддерживают openssl, но там придется морочиться с преобразование ключа.Это реальная головная боль - на текущий момент у нас всего 2 сертификата в которых есть шифрование данных. Почтовые адреса тоже указаны наобум. И уж точно ни в одном действующем сертификате нет ничего про возможности SMIME. (Нашлись сертификаты 2012 года с этими возможностями и после перевода времени в 2012 год почтовик TheBat! согласился их использовать, но по факту они истекли, так что реально использовать не выйдет).2) Все передаваемые по почте данные кодируются в base64, что повышает размер на 30-40%. А шифрование не даст эффективно сжать. Представляете какой ГИС надо иметь почтовый ящик чтобы письма со всей страны его не переполняли.
3) такой единый ящик наверняка засветится (на форумах вроде этого) и будет получать тонны спама. Значит будет спам-фильтр - значит будут срезаться и почта с данными.
С FTP идея получше, но это тоже сводится к созданию учетки для каждого пользователя и chroot. Иначе будут затираться файлы у всех кто "креативно" назвал файл abc.xml или 111.xml. Но можно называть файл через guid. Из плюсов - можно результат выкладывать тоже на FTP. Минусы - FTP относительно медленный протокол (из-за кучи служебных команд) и съедает кириллицу в названиях файлов (это можно обойти если подобрать совместимые клиент и сервер, но лучше кириллицу вообще избегать при работе с FTP), файл с данными испортится если передать в текстовом режиме (обычно можно настроить автопереключение на двоичный режим при передаче файлов), дата изменения по FTP передается крайне безобразно (часто округленно до суток или часов).
Еще есть примерно той же с FTP направленности WebDAV (дополнительное расширение протокола HTTP для изменения файлов на сервере) - тоже создание учетки для каждого пользователя и chroot. Но поудобнее чем FTP в плане кириллицы, передачи времени, выбора режима и есть встроенная поддержка от Windows - можно подключить как сетевой диск. Просто скопировал файл и подпись в папку приема на сетевом диске и ждешь результата в папке результатов. Большинство программ прекрасно работают с сетевыми дисками (пока только cmd и dism на удивление отказались). FTP тоже можно подключить как сетевой диск, но придется залезть вглубь настроек системы - "из коробки" принимаются имена локальной сети. Для сервера поудобнее тем, что папка с результатами может находиться на совершенно другом сервере чем папка для приема данных, но клиент не этого даже заметит. Так что я бы скорее предпочел этот вариант.
С SOAP идея тоже хороша - если и данные и подпись как отдельные вложения в унифицированном SOAP конверте с указанием id шаблона, но без использования xmldsign на SOAP. Все эти способы могут работать через настроенный по сегодняшним требованиям защищенный канал.
[QUOTE]Programmer пишет:
копируешь электронную подпись в файл abc.key[/QUOTE]Все же .key расширение для ключей (в *nix) и называть так файл подписи не очень хорошо. Важно их не путать - ключ один и тот же на все время действия сертификата (и закрытый и открытый), а подпись создается для каждого файла данных отдельно. Общепринято отсоединенный файл подписи называть как .sig или .p7s, то есть если файл c данными назывался abc.xlsx , то автоматическое средство проверки в первую очередь будет искать его подпись в abc.xlsx.sig или abc.xlsx.p7s

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

[SIZE=85px][COLOR=greenpt]Отправлено спустя 2 минуты 21 секунды:[/COLOR][/SIZE]
я вообще расширение .key стараюсь не использовать - редактор реестра на него срабатывает, что несколько раздражает. А на .pem настроил блокнот - удобно смотреть что в файле содержится.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 36 минуты 45 секунды:[/COLOR][/SIZE]
[quote:295jhfhj]ГОСПОДИ! Откуда Вы все это знаете?[/quote:295jhfhj]Полагаю, немного приберусь в файлах и выложу подборку статей по которым все изучал на общедоступный сайт. Сейчас они у меня сохранены на локальном сайте - на случай если исходная удалится. Подчищаю рекламу, посторонние функции и читать становится легче (особенно статьи с хабра - на самом хабре и реклама и куча других отвлекающих статей). Однако локальный сайт на обычной (не серверной) Windows поэтому нормально просмотреть извне не получится.
Для начала [URL=http://pro-ldap.ru/tr/zytrax/tech/ssl.html]cтатья про SSL/TLS, сертификаты, УЦ, ключи, форматы PEM и DER, различия открытых-закрытых ключей[/URL]. Программистам прочитать однозначно советую, чтобы не выглядеть дубом при обсуждении сертификатов. Сайт вообще про службы каталогов, но статья достаточно полно освещает тему сертификатов. Проблема в том, что информации там слишком много и в том числе напрямую не относящейся к "нашим баранам". Поэтому "не-программистам" будет крайне скучно. Если начнете на уровне новичка, то вряд ли дочитаете все за первый раз. По мере надобности не раз еще вернетесь. Ну хотя бы как словарик используйте.

[quote:2t0suuqx]КриптоПро использует ту же OpenSSL[/quote:2t0suuqx]вот как раз про само ядро криптопро что-то не замечал следов использования openssl, слишком уж разное хранение контейнера закрытого ключа (не думаю, что кто-то стырит чужой код и решит абсолютно новый контейнер изобрести) - это то, что собственно продается. Хотя stunnel однозначно из OpenSSL подправили и переходник к OpenSSL естественно не построить без исходников OpenSSL - но эти добавки или бесплатны или используют основную лицензию.
С остальными криптопровайдерами вроде магпро, сигнал ком и компании полностью согласен. В демо магпро версия 1.0.1с, в то время как в мае прошлого года уже была в сети скомпиленная 1.0.2h. Собрать поновее все никак не соберусь - лениво с компиляторов Си возиться ради одной проги.
[quote:2t0suuqx]Для подписи ключ не нужен, нужны лишь его параметры, которые можно один раз получить и хранить например, в ini-файле.[/quote:2t0suuqx]Так, стоп. Что-то я не понял, наверно терминология отличается. По идее для вычисления хеша не нужен закрытый ключ, но для вычисления SignatureValue [B]закрытый[/B] ключ потребуется. Не говорите мне что закодировали в строку pem и сохранили в ini файл. Если же там только параметры, то в них наверняка указан путь к ключу и он достается неявно. С другой стороны, сертификат (содержащий [B]открытый[/B] ключ) можно хранить хоть как и он потребуется при сборке тега Signature.
[quote:2t0suuqx]На каждый метод свой класс, в главном классе вызов методов класса идет по интерфейсной переменой, что упрощает управление памятью и не трогает основную логику.[/quote:2t0suuqx]Интересный подход, я больше склоняюсь к другому - хранить список нужных для версии данных и форматов, потом передавать в некий универсальный класс-построитель эти списки и сами значения данных. Выгода в том, что изменить список гораздо проще чем каждый раз переписывать логику, а недостаток в том, что работать будет медленнее, так как на анализ списка потребуется дополнительное время. Но в общем это тесно завязано с выборкой данных из самой ИС, так что дело автора ИС, что выбрать.
[quote:2t0suuqx]Вам всё еще кажется трудной работа с ёксель-файлом ?[/quote:2t0suuqx]Прошу заметить, что тут еще ненавязчиво выкинули приведение к каноническому виду (дескать наша вручную высеченная ИС сразу дает канонический вид). А если писать с нуля процентов 60 всей работы это как раз написать полностью соответствующий стандарту каноникализатор. Серьезно, почитал стандарт приведения к каноничному виду, в XML открылись такие возможности о которых я даже не подозревал и вряд ли кто в своем уме их вообще использует, но тем не менее их надо поддерживать при приведении. :)

[QUOTE]RatWar пишет:
Компоненты Indy поддерживают OpenSSL, т.о. защищенный канал "из коробки".[/QUOTE]Огромное спасибо! Все замечательно, разве что КриптоПро остался не при делах, а OpenSSL везде или относительно устаревший в котором есть ошибки или не сертифицированный. Ну отдельный класс для каждого отчета править после смен версий ГИС это немного чересчур.

Вставлю 5 копеек о соединении криптопро и OpenSSL, тогда отпадет необходимость в P12FromGostCSP (у меня она вообще вытаскивает непонятно что, пришлось конвертировать через privkey).
1) Как я понял OpenSSL умеет ключ и из памяти брать, так что можно считать закрытый ключ из хранилища сертификатов стандартным криптопровайдером, потом передать OpenSSL.
2) стандартную gost.dll из OpenSSL можно без особых потерь заменить в конфиге на криптопрошную gost_capi.dll (нужно только закомментировать выбор параметров A (кстати у нас все ключи на параметрах exA, так что наверно так правильнее )) и тогда можно из OpenSSL работать с ключами в контейнерах криптопро.

Хм, ну РСО же может выставить по договорам платежки. Почему УК не может? По логике договор обслуживания тоже договор на предоставление услуг.
Другое дело, что это 100% не договор управления. ОМСУ занесет, а дальше может что-то да откроется. Что если занести договор туда же где РСО заносит? Надо где-то почитать про такой случай.

Пожалуйста.[quote:d1hqgczn]Я понимаю, что это файлы pem...[/quote:d1hqgczn]Скорее всего. Вообще PEM это формат ("текстовая" кодировка в base64 данных + текстовые заголовки) и расширение может быть разным. Для сертификатов в PEM общепринято .crt и windows его понимает. Если после изменения .pem на .crt отобразится сертификат, то можно посмотреть чей и все прояснится.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 15 минуты 22 секунды:[/COLOR][/SIZE]
[quote:d1hqgczn]1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются?[/quote:d1hqgczn]В принципе да. Конечно смотря какая именно лицензия.
Во-первых, [B]по подписи XML[/B]. Краем глаза видел где-то на сайте КриптоПро xml-dsign-addin. По названию эта штука как раз для подписи XML, но как я понял для него нужна дополнительная лицензия, поэтому не стал разбираться к чему он addin (дополнение) и подходит ли подписанный файл к ГИС. Почему-то мне кажется, что дополнение к MS Office и к ГИС не очень подходит (предположил что потребует сохранения файла на диск, подписания, потом отправки файла, то есть нарушит "поточность" внутри программы), поэтому не стал докупать, но может быть у кого-то получится настроить и приспособить.

Если все же не допиливать чужое, а делать свое, то Delphi может обратиться к КриптоПро через майкрософтовские функции. Тут ориентиром служит модуль JwaWinCrypt (есть какой-то стандартный Crypt2 WCrypt32.pas, но в нем как я понял несколько устаревшие описания функций и без учета 64-битности) и заголовочный файл от криптопро с описанием констант. Заголовочный файл желательно посвежее от той же версии КриптоПро, что установлена. Обычно они идут с лицензией криптопро для разработчиков. У меня такой нет, нашел явно "несвежий" заголовочный файл. Впрочем скорее всего из всего файла понадобятся только 3-4 константы. В заголовочном файле констант намного больше и комментарии к ним наводят на мысль что таким же образом наверно и зашифрованный канал можно поднять, но я пока не вникал в подробности. Вот 4 константы для получения хэша и подписи, бросившиеся в глаза.[code:d1hqgczn]const PROV_GOST_2001_DH=75; //Тип Криптопровайдера. для ГОСТ большинство криптопровайдеров использует этот, исключение vipnet для него значение типа равно 2
szOID_CP_GOST_R3411='1.2.643.2.2.9'; //Функция хэширования ГОСТ Р 34.11-94
szOID_CP_GOST_R3411_R3410EL='1.2.643.2.2.3'; //Алгоритм цифровой подписи ГОСТ Р 34.10-2001
szOID_CP_GOST_R3410EL='1.2.643.2.2.19'; //Алгоритм ГОСТ Р 34.10-2001, используемый при экспорте/импорте ключей[/code:d1hqgczn]Первая - это тип криптопровайдера, указывается в CryptAcquireContext. Одновременно можно указать nil вместо имени криптопровайдера (тогда программа подхватит почти любой гостовский (кроме vipnet), выставленный "по умолчанию" для типа 75, не обязательно криптопро) или указать полное наименование криптопро (тогда другие гостовские не подхватятся, но сможет подхватится криптопро даже если криптопро не "по умолчанию" для типа 75). Наименование и выставлен ли по умолчанию можно посмотреть в настройках криптопро (там где обычно сертификат устанавливаем, на соседней вкладке).
Вторая - идентификатор функции хэширования, используется вместо szOID_RSA_MD5 в примерах. Смущает, что 94, но похоже та самая. Третья- четвертая - алгоритм подписи, пока я не понял какой именно нужен.
Если программа будет 64 разрядная, то скорее все нужно будет подправить некоторые типы в объявлениях функций.

Вычисленное криптопро значение хэша или подписи нужно будет "перевернуть". Как я понял, фокус здесь в том, что криптопро возвращает результат не в том endian, который требуется стандартом XML-DSIGN и потому приходится первый байт менять местами с последним, второй с предпоследним и так далее. Затем закодировать в base64 (это относительно легко, модулей кодировщиков много, обычно они тесно связаны с модулями для работы с XML или HTML). Далее все полученное соединить в нужном порядке. Это заслуживает отдельного освещения, условно говоря на этом с подписью все.

Во-вторых, [B]защищенный канал[/B]. Криптопро сделала собственную версию stunnel. Как я понял, отдельной лицензии не требуется, скачивание бесплатно с сайта криптопро. Для нее можно также переделать ключ и сертификат в pem формат как и для обычной. При этом вылезут те же самые грабли с неэкспортом .p12 из криптопро.
Однако внимания заслуживает факт, что вместо имени файла ключа в криптопрошном stunnel можно специальным образом указать ссылку на криптопро и [B]считать ключ из криптопро[/B]. Немного неясно, что в этом случае происходит с пин-кодом ключа - на всякий случай лучше бы скопировать контейнер, а то не дай Бог рабочий контейнер заблочится от неправильных пин-кодов.
Как работает пока не проверял, но если не придется возиться с переделкой ключа, все значительно упростится. Правда меня "терзают смутные сомнения", что если прописать криптопрошную gost_capi.dll к обычному stunnel выйдет то же самое. Хотя сертификат все также потребуется в pem, но с этим проблем нет легко переводится через openssl.
Если настроить такой stunnel, то в программе можно не заморачиваться на собственную реализация HTTPS со вкусом ГОСТ, а просто стандартными модулями HTTP соединяться с локальным портом stunnel, а уже stunnel будет соединяться с серверами ГИС, накладывать шифрование, предъявлять сертификат серверу.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 20 минуты 11 секунды:[/COLOR][/SIZE]
[quote:d1hqgczn]2) В данный момент, насколько я понял, достаточно предоставления доступа организацией к собственной тестовой ИС. То есть, ИС не должна просить доступа у организации.[/quote:d1hqgczn]Скорее всего именно так, тестовый позволяет срезать "углы", я не очень подробно изучал этот момент. Однако важно помнить, что: а) для рабочего режима доступ все равно придется запрашивать; б) если срезать много углов и не протестировать все моменты в тестовом режиме, то в рабочем вылезет немало "сюрпризов" и "подводных камней". Читал, что в СМЭВ многие удивились когда рабочий контур проверил электронные подписи и "завернул" с ошибкой сообщения, которые в тестовом контуре проходили успешно. Оказалось тестовый контур игнорирует ошибки в подписи. Поэтому даже если тестовый сервер чего-то не требует, это не значит что нужно это спокойно пропустить.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 5 минуты 23 секунды:[/COLOR][/SIZE]
Можете считать это перестраховкой с моей стороны, но я все равно бы пострался максимально придерживаться процедуры рабочего режима. Раз уж зашла об этом речь, в тестовом режиме еще используется специальный признак тестового режима, при указании которого в рабочем запрос будет отклонен.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 14 минуты 4 секунды:[/COLOR][/SIZE]
[quote:d1hqgczn]3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится.[/quote:d1hqgczn]Да, вот так и собираем истину по крупицам. :)
Как я понимаю, в данном случае зашифрованный канал требует предъявления сертификата клиента, при этом часть данных шифруется при помощи ключа клиента, сервер расшифровывает их ключом проверки из предъявленного сертификата и так доказывается, что у клиента есть ключ, соответствующий сертификату. То есть процедура установления зашифрованного канала по сути аналогична входу по сертификату на ЕСИА. Соответственно, дополнительная авторизация из программы не нужна - ГИС определит пользователя по сертификату защищенного соединения.
Получается передавать данные можно сразу после установления соединения - в смысле сначала заголовки протокола HTTP уточняющие: адрес страницы куда соединяемся, метод (POST я полагаю), тип, кодировку и длину "тела запроса", потом собственно данные в виде "тела запроса". Как-то так, заголовки наверняка описаны в документации, но сложно навскидку найти 1 нужный абзац среди сотен страниц текста.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 59 минуты 54 секунды:[/COLOR][/SIZE]
[quote:d1hqgczn]Вот я сгенерировал PAS из WSDL.[/quote:d1hqgczn]Как-то это меня настораживает. Непохожие языки, как они перегенерятся? Да и вообще вроде XML должен на выходе программы получаться.[quote:d1hqgczn]Какие дальнейшие действия?[/quote:d1hqgczn]Надеюсь немного пролил свет - дальше настроить stunnel, сделать xml, подписать, коннектиться по http на stunnel, передать данные и получить ответ ГИС[quote:d1hqgczn]с какой целью они прислали сертификат обратно[/quote:d1hqgczn]Родилось безумное предположение, что ГИС не принимает сертификаты аккредитованных удостоверяющих центров и они перевыпустили сертификат на своем удостоверяющем центре. Совпадает ли издатель в исходном сертификате и полученном от них?

[QUOTE]g8MF пишет:
В переводе на бытовой язык это означает, что если заявитель несколько раз обращается в инстанцию с одним и тем же вопросом т. к. его не устраивают получаемые ответы (отписки), то должностное лицо  имеет право ему на прощанье написать: «В связи с непониманием Вами  обсуждаемого вопроса и на основании ст. 11, п.5 ФЗ № 59 от 02.05.2006 г – дальнейшая переписка с Вами прекращается», Тоже красиво!!![/QUOTE]Да, с сожалением признаю, вот этим пользуемся. Есть пара особо упорных писательниц, которых ответ никого ниже президента не устраивает и пишут ему уже 5 раз, а оттуда по цепочке спускают в ОМСУ (и 5 областных министерств одновременно). Все 5 раз изложено одно и тоже, хотя и разными словами.

Ну у меня тоже еще все на начальном уровне, но попробую сделать "дайджест". Не очень понятны подробности до чего процесс дошел и с какой целью они прислали сертификат обратно, да еще и со своей подписью (.p7s - это файл отсоединенной подписи, проверить можно через бесплатную версию программы КриптоАрм или на сайте [url:1jrulhzi]https://crypto.kontur.ru/[/url:1jrulhzi] указав оба файла, а вот для создания подписи нужна платная версия). Как я понял, ИС "доработана" (допустим, генерирует сразу каноническую форму XML) и зарегистрирована в тестовом контуре. Подписывать XML ИС уже умеет? Delphi чуть ли не на раз высчитывает значение хэша и подписи через библиотеки MS CryptoAPI и КриптоПро, остается только перевернуть порядок байтов, закодировать в base64 и все правильно соединить.

Далее нужно разрешить доступ к данным своей организации со стороны ИС (то есть видимо надо зайти на ГИС от имени своей ИС и запросить разрешение от своей УК, потом зайти как УК и подтвердить). Далее построить защищенный канал до тестового сервера ГИС. Как я понимаю [URL=https://217.107.108.156:10081/]https://217.107.108.156:10081/[/URL] это один из тестовых серверов с шифрованием, чаще всего используют stunnel на основе OpenSSL. По идее можно найти модули для Delphi с поддержкой HTTPS - как через системные библиотеки TLS, так и через библиотеки OpenSSL. Однако наверно придется залезать куда-то глубоко в дерево классов, что бы указать ГОСТ как алгоритм шифрования. Еще где-то в документации должен быть корневой сертификат ГИС - он также потребуется для построения канала, чтобы ИС не обрывала соединение по причине, что у ГИС не доверенный сертификат.

Далее запулить тестовое сообщение. В декабре там был "косяк" в описании - нужно было указывать организацию совсем не так, как было в документации, не знаю, исправили или нет.

Об этом было чуть выше.[QUOTE]portal-gkh пишет:
так как на данный момент  отсутствует ответственность. А далее - как законодательство повернет.[/QUOTE]Если подробнее, то на данный момент предусмотрена (но отложена на срок выхода ГИС на стабильную работу) ответственность за невнесение данных (про это лучше в соответствующей теме почитать), а вот за недостоверную информацию в ГИС ответственности пока нет (насколько знаю), но конечно соответствующие поправки рано или поздно будут. Причем скорее поздно - сейчас ГИС ЖКХ не готова к установлению такого вида ответственности.[B]В других ФГИС[/B] изначально все данные подписываются усиленной квалифицированной подписью и установлена персональная ответственность того, кто подписал данные. Отвертеться от недостоверных данных очень сложно, так как усиленная квалифицированная подпись (КЭП) сделанная, например, до момента отзыва сертификата, остается действительной даже если сертификат потом отозвали. (В противоположность - не усиленная КЭП становится недействительной не только при отзыве сертификата, но даже при плановом окончании сертификата. Однако в зависимости от ИС, в которой используется, КЭП может быть "усилена" средствами самой ИС.)
[B]В ГИС ЖКХ[/B] на данный момент все замечательно вносится при входе в личный кабинет по паролю, без КЭП. Более того, одни и те же данные могут править несколько организаций, в которых еще больше пользователей. Слетит журнал действий в очередной версии и не докажешь, кто вносил данные через личный кабинет - УО или РСО. По этому поводу много жалоб на газовиков - правят как вздумается, а журнал вообще пуст. В таких условиях нет реальной возможности доказать кто именно ввел недостоверные данные.
С другой стороны, [B]при интеграции ИС[/B] с ГИС большая часть данных подписывается КЭП, то есть, если хранить запросы, можно (хотя и придется долго разбираться в истории правок) вполне однозначно установить подписавшего недостоверные данные.Вывод: ответственность предположительно введут когда всех загонят на СОАП, но это явно не в текущем году и даже наверно не в следующем.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 13 минуты 20 секунды:[/COLOR][/SIZE]
Кстати, отдельный вопрос про то, что  некоторые данные могут быть указаны по разному в разных документах. Каждая сторона предъявит свой документ и подтвердит данные.

[QUOTE]Basil пишет:
Не только. Возможна ситуация, когда платёж поступил на наш р/с, а банк его в ГИС не загрузил[/QUOTE]Собственно, я сначала написал "только", потом стер именно потому что ситуации бывают разные. Тем не менее, два наиболее важных фактора сохраняются - 1) по законодательству обязанность это делать лежит на банке (либо платежном агенте), то есть делаете исключительно для облегчения квитирования; 2) это происходит после поступления на р/с, когда квитирование уже допустимо.

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

А так... кто-то здесь писал, что выбрали самую распространенную модель счетчиков и вдохновенно сочинили последовательные номера, такие, которых у счетчиков этой марки не бывает (по количеству цифр наверно). И теперь сразу видят где реальные данные, а где сочиненные. При простой проверке данных на целостность/полноту такое вряд ли обнаружится, а при должной фантазии можно вообще сочинить номера похожие на идентификаторы ГИС и в случае чего отвертеться, что по неведомой причине ГИС показывает идентификаторы вместо номеров. Однако конечно если глубоко и направлено копнет какой-то специалист, то это вскроется и что-то светит за недостоверные данные.