Также интересно почему никто не рассматривает альтернативные возможности по защите HTTP трафика от подмены?
К примеру поставить перед старым сервером, раздающим HTTP, некий прокси, который сам будет чего-то добавлять (хеши, цифровую подпись и т.п.) в контент (заголовки, куки) анализируя которые некое браузерное расширение (которому все доверяют) выдавало бы предупреждение если контент был изменен.
Ну или какое-то подобное решение, которое позволит не особо напрягаясь и не влезая в дебри настроек этого старого сервера хоть как-то защитить от подмены HTTP контент, который он раздает, без использования услуг третьих лиц (центров сертификации и т.п.).
Проблема в том, что мало кто из патентных поверенных и других лиц принимающих участие в патентовании, обладает достаточной специализированной экспертизой чтобы не выдавать патенты на давно известные подходы к представлению структур данных и способам их хранения в БД.
В данном конкретном случае человек запатентовал комбинацию из двух давно известных методик хранения данных: "Связный список" и "Сущность Атрибут Значение" и никто ему на момент патентования этого не объяснил, но ему это подробно изложили в комментариях к вышеупомянутым публикациям. Хотя это уже по сути не имеет никакого значения — патент уже получен и он может троллить этим патентом всех кто использует эти методики, ту же Magento например.
А еще, как выяснилось — можно патентовать структуру хранения данных в БД, составные индексы к БД и много чего еще: habr.com/post/358934 habr.com/post/414255
Вопрос к Stanislav_F:
Что можете сказать по поводу патента, обсуждаемого в указанных публикациях?
Не понятна новизна решения. Принципиальных отличий от EVA нет. Подобная идея скорее всего приходила в голову не один раз каждому архитектору и продвинутому разработчику.
Это не таблица, это выборка из таблиц.
Трансформация структуры — это когда… конечная структура содержит всю информацию для однозначного обратного преобразования.
Если мне заплатят, то я могу все таблицы Magento с их данными свести к одному Adjacency List, который будет содержать всю информацию для
однозначного обратного преобразования
Точно также как и привести ее к вашей структуре (которая является разновидностью Adjacency List) с возможностью обратной трансформации. Означает ли это, что Magento нарушает ваш патент?
Т.е. если кому-то понадобится использовать в своем ПО таблицу аналогичную вашей
из 5 полей: ID, родитель (ID), тип (тоже ID), порядок среди равных (число), значение (набор байтов)
и все, автоматически вытекающие из этой структуры варианты запросов к этой таблице — он не нарушит ваш патент?
Ели нет — то зачем тогда это нужно было патентовать?
Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
Еще раз, выше я писал, что парой-тройкой джоинов можно трансформировать практически любое EAV хранилище к вашей структуре.
Вот для примера код для Magento:
SELECT
`product`.`entity_id` AS `ID`,
`parent_id` AS `Parent ID`,
`entity_int`.`attribute_id` AS `Type ID`,
`sort_order` AS `Order`,
`value` AS `Value`
FROM
catalog_product_entity AS `product`
JOIN catalog_product_relation AS `relation`
ON product.entity_id = relation.child_id
JOIN catalog_product_entity_int AS `entity_int`
ON product.entity_id = entity_int.entity_id
JOIN eav_entity_attribute as `attribute`
ON entity_int.attribute_id = attribute.attribute_id
Он выбирает `ID`всех простых товаров, которые входят по `Parent ID` в составные товары, для каждого `ID` выбирается тип целочисленного атрибута `Type ID` отсортированный по порядку аттрибутов `Order` со значением `Value`, на выходе получаем что-то вроде такого:
Чем эта таблица отличается от вашей?
Даже еще хуже, после первого выстрела у вас уже не играют две каморы, т.к. мы знаем что патроны заряжены последовательно. Т.е. шанс быть убитым без прокрутки — 1/2, а с прокруткой — 1/3, т.е. надо крутить, чтобы шанс выжить был выше.
Если стрелять второй раз, то у вас уже не играет пустая камора барабана, выпавшая в первый раз. Т.е. у вас играют два патрона в пяти каморах. А если крутануть барабан, то у вас играет еще раз эта же пустая камора, т.е. у вас снова два патрона в шести каморах. Вероятность быть убитым без прокрутки 2/5, с прокруткой 2/6, т.е. с прокруткой вероятность быть убитым — меньше.
Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
Да вот как раз можно, просто в Magento (да и в любой другой аналогичной системе) информация разделана на несколько таблиц из которых парой-тройкой джоинов можно получить вашу таблицу.
Еще раз повторюсь, вы запатентовали вполне себе очевидную, я бы даже сказал — тривиальную структуру данных.
Скорее всего это сделано чтобы не перегружать схему. Видимо автор хотел показать только зависимость по типу атрибута. Я конечно не художник, но с entity_id будет выглядеть как-то так:
К примеру поставить перед старым сервером, раздающим HTTP, некий прокси, который сам будет чего-то добавлять (хеши, цифровую подпись и т.п.) в контент (заголовки, куки) анализируя которые некое браузерное расширение (которому все доверяют) выдавало бы предупреждение если контент был изменен.
Ну или какое-то подобное решение, которое позволит не особо напрягаясь и не влезая в дебри настроек этого старого сервера хоть как-то защитить от подмены HTTP контент, который он раздает, без использования услуг третьих лиц (центров сертификации и т.п.).
В данном конкретном случае человек запатентовал комбинацию из двух давно известных методик хранения данных: "Связный список" и "Сущность Атрибут Значение" и никто ему на момент патентования этого не объяснил, но ему это подробно изложили в комментариях к вышеупомянутым публикациям. Хотя это уже по сути не имеет никакого значения — патент уже получен и он может троллить этим патентом всех кто использует эти методики, ту же Magento например.
18 тоже есть, но в начале года.
habr.com/post/358934
habr.com/post/414255
Вопрос к Stanislav_F:
Что можете сказать по поводу патента, обсуждаемого в указанных публикациях?
Как я уже комментировал в прошлой статье, но так и не дождался ответа от UltimaSol:
Достаточно погуглить по create table parent_id type_id и вы найдете кучу решений использующих этот подход задолго до вас! Он настолько очевиден, что люди даже используют такие же имена полей — вот парочка ссылок с первой же страницы поиска:
2013 CREATE TABLE myproducts (uid, parent_id, type_id, name ...
2007 CREATE TABLE menu_menuitem (id, parent_id, type_id, order, title ...
2013 CREATE TABLE myproducts (uid, parent_id, type_id, name ...
2007 CREATE TABLE menu_menuitem (id, parent_id, type_id, order, title
Ели нет — то зачем тогда это нужно было патентовать?
Вот для примера код для Magento:
Он выбирает `ID`всех простых товаров, которые входят по `Parent ID` в составные товары, для каждого `ID` выбирается тип целочисленного атрибута `Type ID` отсортированный по порядку аттрибутов `Order` со значением `Value`, на выходе получаем что-то вроде такого:
Чем эта таблица отличается от вашей?
Еще раз повторюсь, вы запатентовали вполне себе очевидную, я бы даже сказал — тривиальную структуру данных.