Вы подразумеваете что это кеш, и он в БД хранится? Какой еще HTML страниц в битриксе может "прилетать из БД"?
Тут наша ошибка в статье, спасибо, исправили. Тут речь не о БД, а о backend’е, что с него прилетает весь html и стили. В БД запросы делаются, если это требуется (например, кэш устарел или не был еще создан). Все расчеты/выборки так же кэшируются при необходимости на стороне Битрикс (т.е. backend’а). Но хранится не html кэш, а кэш самих данных. И возвращаются именно они.
А на первый запрос, при отстутствии такого кеша, хоть каким методом передачи будет одинаковое время на ответ затрачено, потому что надо те-же самые расчеты выпонить.
В случае первого запроса (когда пользователь первый раз открыл сайт), время ответа будет “одинаковое”, т.к. будет возвращен html целиком, как и в случае использования просто Bitrix. Будем ли мы использовать чистый Bitrix или связку Nuxt+Bitrix, это не важно, т.к. логика функционала будет одна и та же, и кэш мы будем использовать так же.
Если говорить о втором и последующих запросах, то тут увеличение скорости заключается в том, что с backend’а на каждый запрос прилетает не “5мб” информации (в виде html), а “50 кб” (в виде json).
В случае с DSS используется схема с оператором — организация заключает договор с Крипто-Про и может выдавать сертификаты как бы от лица Крито-Про.
На практике это выглядит примерно так: ответственный сотрудник со стороны организации проходит инструктаж в Крипто-Про, и ему выделяется специальный доступ к системе Крипто-Про, которая позволяет выдавать сертификаты сотрудникам. Таким образом организация становится оператором.
Оператор согласно регламенту (установленным Крипто-Про) совершает выдачу сертификата сотрудникам: собирает документы, удостоверяющие личность, принимает заявление и в специальной системе создает и выдает сертификат.
В случае с DSS lite ключ выдает Крипто-Про по стандартному протоколу с одной лишь разницей, что в ключ встроен маркер доступа к сервису DSS lite. По этой причине использовать DSS lite с другой подписью (даже той, что выдал Крипто-Про ранее), нельзя.
Каждый сам решает, какая цена для него приемлема. При этом, необходимо отметить, что в материале стоимость решения не указана. Для крупной распределенной компании она не так высока, как могут подсказывать стереотипы о продукте.
Повторимся, мы видели это письмо, и заказчик с ним знаком.
Юридически значимой ПЭП будет при выполнении следующих условий:
Соглашением установлена однозначная, не допускающая толкований, связь публичной части ключа ПЭП (в нашем случае логина от учетной записи) с Удостоверением Личности пользователя.
Закрытая часть ключа ПЭП (пароль от учетной записи) строго конфиденциальна и это зафиксировано в соглашении.
И в этом случае есть несколько сложностей:
Соглашение между сторонами, использующие ПЭП. Авансовые отчет — это первичный документ, проверяемый ФНС, таким образом ФНС формально также должна участвовать в соглашении.
Пароль должен быть известен ТОЛЬКО владельцу, т.е. единственному и определенному лицу, а как же администратор в корпоративной сети?
В банках (например, Сбербанк) при совершении операций (заключение договора, открытие вклада и т.д.) вместо живой подписи используется банковская карта и введение ПИН-кода, таким образом это своего рода ПЭП. Заметьте, просто прийти и поменять ПИН-код к карте нельзя, только перевыпуск карты. По тем же причинам изменений в сертификате ЭЦП всегда сопряжен с его перевыпуском.
Открытый ключ ПЭП должен содержаться в передаваемом документе. Можно, конечно, просто в самом документе указать логин подписанта, но такой документе не защищен от изменений, поэтому дописать и удалить можно все, что угодно. А доказывать саму транзакцию совершения операции подписания внутри корпоративной системы то ещё занятие.
Пути обхода и решения вышеуказанных сложностей действительно существуют, но мы, будучи технарями, а не юристами, не готовы нести ответственность за закрытие данных вопросов — только консалтинг. Вероятно, у юристов Заказчика слишком много своей работы, чтобы погружаться в данную область, искать «подводные» камни, составлять и заключать грамотное соглашение, не упустив нюансов. Цена ошибки высока: не принятые авансовые очтеты --> ложные данные в итоговой отчетности --> большие штрафы для организации.
Поэтому клиент, выбрав проверенный вариант использования ЭЦП, решил как минимум перестраховаться.
Тут требования клиента в плане админки и функционала скидок, корзины и т.д. Ему админкой пользоваться удобно.
Конечно, если бы это было возможно, мы бы взяли более легкий фреймворк, и не обязательно даже на php.
Тут наша ошибка в статье, спасибо, исправили. Тут речь не о БД, а о backend’е, что с него прилетает весь html и стили. В БД запросы делаются, если это требуется (например, кэш устарел или не был еще создан). Все расчеты/выборки так же кэшируются при необходимости на стороне Битрикс (т.е. backend’а). Но хранится не html кэш, а кэш самих данных. И возвращаются именно они.
В случае первого запроса (когда пользователь первый раз открыл сайт), время ответа будет “одинаковое”, т.к. будет возвращен html целиком, как и в случае использования просто Bitrix. Будем ли мы использовать чистый Bitrix или связку Nuxt+Bitrix, это не важно, т.к. логика функционала будет одна и та же, и кэш мы будем использовать так же.
Если говорить о втором и последующих запросах, то тут увеличение скорости заключается в том, что с backend’а на каждый запрос прилетает не “5мб” информации (в виде html), а “50 кб” (в виде json).
Не совсем, в связке именно с Bitrix для достижения максимальной производительности приняли решение джойнить запросы на бэке.
В случае с DSS используется схема с оператором — организация заключает договор с Крипто-Про и может выдавать сертификаты как бы от лица Крито-Про.
На практике это выглядит примерно так: ответственный сотрудник со стороны организации проходит инструктаж в Крипто-Про, и ему выделяется специальный доступ к системе Крипто-Про, которая позволяет выдавать сертификаты сотрудникам. Таким образом организация становится оператором.
Оператор согласно регламенту (установленным Крипто-Про) совершает выдачу сертификата сотрудникам: собирает документы, удостоверяющие личность, принимает заявление и в специальной системе создает и выдает сертификат.
В случае с DSS lite ключ выдает Крипто-Про по стандартному протоколу с одной лишь разницей, что в ключ встроен маркер доступа к сервису DSS lite. По этой причине использовать DSS lite с другой подписью (даже той, что выдал Крипто-Про ранее), нельзя.
Каждый сам решает, какая цена для него приемлема. При этом, необходимо отметить, что в материале стоимость решения не указана. Для крупной распределенной компании она не так высока, как могут подсказывать стереотипы о продукте.
Повторимся, мы видели это письмо, и заказчик с ним знаком.
Юридически значимой ПЭП будет при выполнении следующих условий:
И в этом случае есть несколько сложностей:
В банках (например, Сбербанк) при совершении операций (заключение договора, открытие вклада и т.д.) вместо живой подписи используется банковская карта и введение ПИН-кода, таким образом это своего рода ПЭП. Заметьте, просто прийти и поменять ПИН-код к карте нельзя, только перевыпуск карты. По тем же причинам изменений в сертификате ЭЦП всегда сопряжен с его перевыпуском.
Пути обхода и решения вышеуказанных сложностей действительно существуют, но мы, будучи технарями, а не юристами, не готовы нести ответственность за закрытие данных вопросов — только консалтинг. Вероятно, у юристов Заказчика слишком много своей работы, чтобы погружаться в данную область, искать «подводные» камни, составлять и заключать грамотное соглашение, не упустив нюансов. Цена ошибки высока: не принятые авансовые очтеты --> ложные данные в итоговой отчетности --> большие штрафы для организации.
Поэтому клиент, выбрав проверенный вариант использования ЭЦП, решил как минимум перестраховаться.