Comments 8
А вот в плане работы веб-сайта, подпись запросов — это каждый http запрос, грубо говоря подписывать надо или как? Извините, если некорректно вопрос поставил, я не особо в теме.
В плане работы веб сайта подписывать ничего не надо, потому что никто от вас этого не требует (я считаю это требование абсурдным). Если вы хотите выкладывать подписанные документы, то к документу вы должны прикладывать хеш документа, подпись, метку времени и публичный сертификат. Это необходимо для доказательства подписи документа, существования подписи документа на какой то момент времени и подписавшего.
Если кратко, то как-то так.
Если кратко, то как-то так.
Я не согласен с Вашей схемой, что будет если клиент не имеет внешнего адреса, как сервер запросит у него подтверждение получения ответа?
Предлагаю немного другую схему:
1) клиент запрашивает данные
а) сервер вернул нужные данные — регистрируем получение ответа
б) сервер либо недоступен, либо вернул неверные данные — регистрируем результат (с уведомлением клиента о неудачной попытке, и сервера по другому каналу связи)
2) клиент отправляет подтверждение о получении ответа серверу
Таким образом каждый из них будет иметь полную информацию о текущем состоянии процесса.
Предлагаю немного другую схему:
1) клиент запрашивает данные
а) сервер вернул нужные данные — регистрируем получение ответа
б) сервер либо недоступен, либо вернул неверные данные — регистрируем результат (с уведомлением клиента о неудачной попытке, и сервера по другому каналу связи)
2) клиент отправляет подтверждение о получении ответа серверу
Таким образом каждый из них будет иметь полную информацию о текущем состоянии процесса.
Все проблемы о которых я говорил имеются:
1. Клиент может не доказать, что его запросы не принимаются или не обрабатываются.
2. Соответственно сервис может утверждать, что к нему запросы не поступали.
3. Сервис может утверждать, что ответы не приходят в связи с проблемами транспортной среды при длительной обработке запроса.
4. Сервис может утверждать, что ответы он отправляет, но клиент их не получает или не сохраняет.
5. Клиент может утверждать, что ответы он не получает.
Например: Мы запросили отчет, на формирование которого уходит продолжительное время или вообще обработка происходит во время появления свободных мощностей. За это время вероятность обрыва tcp сессии велика. Плюс если сервер тупо не отвечал клиенту (рушился без какого либо ответа во время обработки запроса и закрывал сессию) и фигушки вы докажите, что позавчера я принимал запросы, но не обрабатывал их. В то же время процедура приема сообщения и ответа о принятии настолько проста по сравнению с остальными обработками, что вероятность появления ошибки в ней меньше на много порядков.
Далее. О какой системе мы можем говорить, если для взаимодействия с ней она не может получить внешний или специфический адрес. Для меня эта проблема высосана из пальца, потому что интегрируемые системы со всеми требованиями, которые я описывал:
а) серьёзные
б) внешний адрес для них смехотворная проблема
в) Очень часто ходят ещё и внутри какого-нить впн
в.1) В частности они могут ходить ещё и внутри какой-нибудь закрытой сети.
Суть проблемы не простое техническое решение, а максимально непретензионное со стороны других лиц. Ещё раз перечитайте пожалуйста бумажный вариант и проблемы в простой технической реализации. Ии разжуйте мне, чего я не понимаю в вашем варианте.
1. Клиент может не доказать, что его запросы не принимаются или не обрабатываются.
2. Соответственно сервис может утверждать, что к нему запросы не поступали.
3. Сервис может утверждать, что ответы не приходят в связи с проблемами транспортной среды при длительной обработке запроса.
4. Сервис может утверждать, что ответы он отправляет, но клиент их не получает или не сохраняет.
5. Клиент может утверждать, что ответы он не получает.
Например: Мы запросили отчет, на формирование которого уходит продолжительное время или вообще обработка происходит во время появления свободных мощностей. За это время вероятность обрыва tcp сессии велика. Плюс если сервер тупо не отвечал клиенту (рушился без какого либо ответа во время обработки запроса и закрывал сессию) и фигушки вы докажите, что позавчера я принимал запросы, но не обрабатывал их. В то же время процедура приема сообщения и ответа о принятии настолько проста по сравнению с остальными обработками, что вероятность появления ошибки в ней меньше на много порядков.
Далее. О какой системе мы можем говорить, если для взаимодействия с ней она не может получить внешний или специфический адрес. Для меня эта проблема высосана из пальца, потому что интегрируемые системы со всеми требованиями, которые я описывал:
а) серьёзные
б) внешний адрес для них смехотворная проблема
в) Очень часто ходят ещё и внутри какого-нить впн
в.1) В частности они могут ходить ещё и внутри какой-нибудь закрытой сети.
Суть проблемы не простое техническое решение, а максимально непретензионное со стороны других лиц. Ещё раз перечитайте пожалуйста бумажный вариант и проблемы в простой технической реализации. Ии разжуйте мне, чего я не понимаю в вашем варианте.
Неудивительно слышать такие вещи о нашем электронном правительстве. Я знал, что и с подписями у них не все гладко, раз с простыми паролями такая фигня…
А можно вопрос: работает ли ЭЦП в линуксе?
Работает, если у вас есть криптопровайдер или сдк с функционалом криптопровайдера.
Ну и если понудить: ЭЦП не работает, оно формируется. Работает криптопровайдер. Ему нужен сертификат.
Сертификат это не ЭЦП. ЭЦП если совсем просто — это набор символов.
Ну и если понудить: ЭЦП не работает, оно формируется. Работает криптопровайдер. Ему нужен сертификат.
Сертификат это не ЭЦП. ЭЦП если совсем просто — это набор символов.
Sign up to leave a comment.
Электронный документооборот, ЭЦП и интеграция систем. Философские выводы за бокальчиком вина