Каноническая логика, native-решения и SQL инъекции

Я идеологически предполагаю (и верю), что существует каноническая логика при решении любых вопросов. Этот термин следует иметь в обиходе общения, так как он важен, при принятии любых архитектурных решений. Решения, которые основаны на использовании такой логики, можно назвать native-решения, естественные решения. Рассмотрим этот вопрос в области SQL инъекций и архитектурных решений в прилегающей области...

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

Чаще всего архитектурные решения принимаются с использованием смеси логик: канонической, ошибочной и идеалистической. В начале, когда нужно что-то построить используется "мысленное каноническое движение" - проблема решается естественным, наиболее простым способом - это есть каноническая логика. Далее ввиду того, что условия задачи, как чаще всего бывает, не определены идеально, делается просчет и ориентация на возможные области использования архитектурного решения, с целью покрыть возможные в будущем, не до конца ясные цели в текущем времени. Это самый сложный этап архитекторов, на этом этапе примешивается ошибочная логике в архитектурном решении. И на последнем этапе, как чаще всего бывает, для простых сущностей используется идеалистическая логика, чтобы покрыть максимум нужных или не нужных областей использования архитектурного решения.

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

К сожалению в области компьютерной цифровой техники налицо имеется множество ошибочной логики в архитектурных решениях, из-за логической сложности, и мы имеем чрезвычайные потери ресурсов - энергии и прочих в связи с этим. Из-за обратной совместимости решения не могут быть переделаны. Хотя я бы не взялся утверждать, что однажды человечество не создаст "digital-thread-2" в области цифровой техники абсолютно не совместимый с настоящей цифровой техникой. Возможным противодействием для этого, вижу только лишь вероятность появления квантовой техники и полный медленный уход от классической цифровой.

Во время архитектурных решений при разработке реляционных БД SQL запросов, каноническая логика в том, чтобы не допустить возможность SQL инъекций в принципе, на фундаментальном уровне на основе шаблонных подстановок для внешних переменных. Это больше касается реальных практических реализаций, нежели абстрактного стандарта SQL, хотя и в нем следовало бы стандартизировать шаблонные подстановки. Зачем разрабатывать нечто, что заведомо имеет проблемы, в то время как их можно устранять на архитектурном уровне? Реальная ситуация такова, что шаблонные подстановки не есть фундаментальными сущностями практических реализаций БД и это оправдывается их архитектурно-идеалистическим стремлением. Но в этом заключена ошибочная логика! Нет оправдания подобному идеалистическому стремлению!

В HTTP протоколе в параметрах query string, следовало бы стандартизировать, что ключами параметров, могут быть только простые идентификаторы, а не произвольные данные включая кавычки! Другие символы должны преобразовываться, например в символ подчеркивания браузерами и серверными языками программирования. В этом есть каноническая логика верного архитектурного решения. Даже в идеалистичеcком смысле ключ это не данные и не следовало бы допускать произвольные символы для его построения. Такие меры никак бы не ослабили возможности протокола, но уменьшили бы вероятность инъекций в практических реализациях.

Я думаю, плохие архитектурные решения стандартов, в мировом масштабе, ведут к грандиозным потерям энергии и других ресурсов человечества! Пора популяризировать проект SKY и создать "комитет архитектурных просчетов стандартов", чтобы ясно понимать, что теряет человечество из-за плохих архитектурных решений. Может таковой и есть уже? Не знаю.

Потери энергии и других ценных ресурсов человечества происходят при любых глобальных архитектурных просчетах. Приведу пример не связанный с инъекциями, но в котором достаточно легко просчитать потери энергии. Вопрос касается кодировок символов ASCII и UTF-8. Все мы знаем, что один байт допускает 256 комбинаций кодов из них ASCII включает только лишь 26 букв английского алфавита. Прописные плюс строчные, итого алфавит занимает 52 кода. 256 / 52 = почти одну пятую, четыре пятых остается. Суть в том, что потенциально возможно было бы закодировать символы кириллицы и языки германской группы одним байтом. Иероглифы и арабские символы скорее всего не поместились бы и для них нужно было бы использовать коды 2-3-х байтные. Хорошо было бы изначально создать кодировку со схемой кодирования подобно как в UTF-8, где было бы однобайтных символов 256/4*3 = 192 символа, а 64 для расширенных много байтовых само-синхронизирующихся последовательностей.

Общее среднее количество потребляемой электрической энергии людьми на всей Земле довольно точно известно. Также известно количество людей или передающейся по сети Интернет текстовых символов на кириллических языках или языках германской группы, которые сейчас занимают в UTF-8 2 или более байт. Суть в том, что несложно посчитать насколько динамичнее была бы передача по сети Интернет передача таких текстовых данных. А с энергией просто: передавая один байт, вместо двух-трех и потери были бы в 2 раза меньше.. В масштабах человечества это огромная цифра и большие деньги, которые тратятся впустую! Сейчас стандартом определено, что в новом HTML5 (который естественно рекомендуется использовать) следует использовать UFT-8. Хорошее архитектурное решение со времен создания ASCII, могло бы изначально содержать кодировку построенную по принципам описанным здесь выше. История же создания и использования кодировок, выглядит как тяжелые роды UTF-8, которая и сама по себе могла бы быть лучше, но не может быть лучше из-за проблемы обратной совместимости.

Символы ASCII с кодами ниже 32 по большей части не используются, хотя легко было понять, что часто используемые символы должны иметь короткий код, а редко используемые - длинный. Из них одно-байтовыми можно было бы сделать только лишь \x00, \x0a, \x09.

Конечно, не все зависело от архитекторов и создателей ASCII (не было в их власти), но тем не менее веб, в данный момент пришел к более-менее хорошему детерминированному решению - использованию UTF-8 в HTML5.

В общем, моя интуитивная оценка такова, что КПД развития современной цифровой техники составляет не выше 50%, т.е. потенциально она могла бы работать минимум в 2 раза эффективнее по многих критериям. Это низкое и досадное значение.
published ENERGY - 26 Aug 2017 06:21 GMT
last edit - 28 Aug 2017 08:38 GMT
 +  0  -  add comment