Как стать автором
Обновить
6
0

Пользователь

Отправить сообщение
Коротко и по-делу, спасибо. Многие действительно путают эти два в корне разных понятия!
Хрология = хронология, исправьте под-ста! Материал очень интересный, спасибо!
Все это очень знакомо:) солидарен с автором. Наличие широкого стека знаний и технологий является большим плюсом, если ты собственник айтишного бизнеса.
Я начинал учиться именно с плюсов, точнее с си по книге Кернигана/Ричи и потом плюсы с ооп. Джава, пхп, перл, жс потом зашли отлично.
а еще есть старая инженерская поговорка, которая гласит, «если что-то работает — не трогай его»)))
Коротко и ясно, респект! Попробую развернуть аналогичную конфигурацию, у нас офисе на убунте
Я тоже не понял о чем тогда книга. По статье — сами применяли стек из nodejs+ws+rabbitmq. Это действительно очень эффективно.
Не знаю насчет T9, но iOS с которого писался коммент — да, на C)))
Поддерживаю. Конкретно, стоило бы упомянуть книгу, которую многие разработчики, как и я считают ни много не мало Библией Программиста:
Брайан Керниган, Деннис Ритчи — The C Programming Language
*Согласен с авторами, сорри:)
Могла не с авторами. Как и многие программисты, начинал именно с С, причем по классической книге Кернигана/Ричи и очень благодарен этому опыту. Java и PHP с этим бэкгрундом зашли очень легко
Бывает целый ряд задач, когда к доверенному серверу через HTTPS подключается множество недоверенных клиентов, и реализация не предусматривает возможность добавлять авторизацию по клиентским сертификатам. Далеко не ходить за примером — API почти всех платежных систем используют HMAC в том или ином виде.
Хм, интересно, на практике все работало нормально, нужно будет провести больше тестов.
Прочитайте статью внимательнее, там специально делается рекурсивная сортировка массива по ключам перед сериализацией в JSON и функция для этого написана.
Контроль на форме, навязанный платежной системой, как минимум, может защитить клиента-мерчанта от таких детских векторов, которым они, увы, зачастую подвержены.
Нам с вами очевидно — мерчанту далеко не всегда. Я сам лично неоднократно встречал такие векторы и успешно их эксплуатировал.
Вариантов масса, в зависимости от бизнес-логики интернет-магазина при обработке Result от платежной системы. Если интернет-магазин проверяет на Result только ID заказа и не проверяет сумму — вектор очевиден.
Я тоже не ленивый, еще раз отвечу — от изменения пользователем данных формы. Разумеется, при условии, что контролируются лимиты.
Теперь я понял о чем вы. Безусловно, это так. И именно поэтому в наших решениях HTTPS используется абсолютно везде по-умолчанию, а HMAC/CSRF-токены (+ лимиты соединений) реализуют дополнительный слой для аутентификации и контроля логической целостности сообщений.
Ну если учитывать, что клиентская сторона это в большинстве случаев страница чекаута в интернет-магазине, там скорее всего обычный HTTP, но я все же немного не улавливаю суть вопроса, на что это влияет, если форма в любом случае доступна пользователю браузера.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность