LO-7.2

Автор Kadet, 26 августа 2021, 23:20

0 Пользователи и 2 гостей просматривают эту тему.

economist

Приложение, использующее RDBMS может хранить все настройки в отдельной таблице БД. Или в константах модуля в одном месте. Или в текстовом INI-файле на диске. 
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

Kadet

#166
М-да. Заморочка со свойствами в Base.
Конечно, можно найти и более хитрые способы, но, снова, я искал более лёгких путей, коих получается нету.

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

Почему-то, в LO Base очень часто приходится прибегать ко всякого рода хитростям и изворотам.

economist

#167
Kadet - мне кажется вы сильно (эволюционно) переусложнили свое решение. Вот пара мыслей "теоретика" по паролям для защиты LO-приложений от копирования у клиентов и где их хранить. Нам, LO-шникам, в чем-то повезло, но тема слабо документирована, так что везение оказалось ложным. Везет в том что Модуль на почти любом языке Basic/Python/С++/Java/JS(?), даже запароленный - можно вручную/полуавтоматом встроить в сам ODF-документ, или разместить модуль в LAN, и даже WAN, на сайте. Но вот делать так иностранные программисты не советуют, потому что реверс-инженеру с расценкой 300 Евро/час, владеющему отладчиком - несложно за часы понять что и где и промэпить все случаи вызова и ответа модуля, написать рабочий патч, зарулив на него все check-вызовы.

Для Excel написано много подобного прикладного софта (складских "помогает" - в тысячи раз больше, чем для LO). И ведь VBA-проекты в MS Excel - родными методами не защитишь, всё до сих пор (с 1995 г.) вскрывается заменой одной буквы на другую в любом редакторе (типа FarManager), за минуту. Для LO подобных простых гайдов по снятию пароля я не находил, возможно их и нет. Но...

Программисты с зарубежных форумов неустанно советуют пароли хранить не в документе, не в модулях, не глобальных константах, не возиться с их "передачей" в процедуры разных модулей, сталкиваясь с непонятками вроде ваших, а хранить пароли в виде хешей (отпечатков пароля) в отдельных текстовых файлах, куда они бесхитростно запишутся в несколько строк кода, например, на Python (только потому что для него море примеров, а для Basic - единичные на старых OO-форумах).

Для Python есть хороший модуль PyArmor с кучей однострочных примеров, который по железу (номер диска/тома/раздела, ID CPU/MB, внешнему IP-адресу итд - т.е. тут полный фарш готовых привязок к "железу", включая триальные) сделает вам готовый MachineID. Да и готовых отдельных либ для чтения/генерации MachineID - хватает, их десятки (Basic явно проигрывает, тут без внешнего "Scripting.FileSystemObject" даже серийный номер тома C:\D: не считаешь, да и он - "проживет" лишь до следующей переустановки винды и его, как и EMEI, можно подделывать утилитами Руссиновича).

Введенный пароль, по сути - "соль", не зная, может вводить даже сам клиент, например свой ИНН), во время установки или первого запуска (хотя чаще вы выдаете/присылаете/позволяете скачать с GoogleDrive хеш-файл по MachineID клиента). Одним словом, ваш макрос запишет хэш пароля/ID машины и хеш от соли на диск в txt-файл. Суть хеширования - невозможно по хешу вычислить пароль, поэтому хеш не нужно прятать, пусть лежит явно.

А дальше все сразу становится просто: ваши макросы в приложении могут кое-где и лишь иногда сравнивать хэш с хэшем во внешнем TXT-файле, читать которые Basic умеет быстро и бесконфликтно (в pyarmor для этого написаны замудреные, но быстрые функции, которые даже прятать/обфусцировать не надо). Таким образом на другом PC - программа запустится, но работать будет не во всём или не всегда. Именно такая ненавязчивая и незаметная поначалу защита, вкупе с невысокой ценой на доплицензии и его регулярным улучшением (с поддержкой) в новых релизах, являются, кмк, лучшей защитой от пиратства.

Учитывая среднестат. "воронку продаж в деловом ПО в РФ" 50:1 (из 50 ЮЛ/ИП которые скачали вашу демку - купит ~1) - можно послушать совета больших программистов и сделать отдельную демо-версию или даже Lite-версию по принципу donationware, на другом "встроенном" движке (я опять про SQLite - там все запросы незакавыченные, и диалект SQL92 в полный рост и перевод не должен быть сложным). Лично для меня эта ветка стала хорошим сигналом не использовать FB Embed движок в Base ни для каких целей, уж больно много странностей вылазит по факту.
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

Kadet

#168
economist, спасибо за информацию!
Пока вопрос защиты такого уровня передо мною не стоит. К тому же, мои заказчики чаще не слишком "спецы" в программировании и т.п. А если у них и есть спецы способные расковыривать защиту, то вряд ли они обратились бы ко мне.
Поэтому считаю, что на данном этапе существующая защита вполне достаточная.

Однако, после того как я закончу основную свою "горячку" по созданию последней программу по заказу, то планирую обратиться к этой теме и детально разобраться в ней.

Однако, спасибо!

mikekaganski

#169
Цитата: Kadet от  2 сентября 2021, 11:45
Можно попросить Вас проверить работу ваших исправлений на моей дополненной демке (# 148) и в моей базе (Cyanopica4) на запросах:
SELECT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" GROUP BY "Заказчик", "ID"  ORDER BY UPPER("Заказчик") ASC
SELECT DISTINCT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" ORDER BY UPPER("Заказчик") ASC
SELECT list("Размер",';') FROM (SELECT DISTINCT "Размер" FROM "РАЗМЕРЫ" WHERE "Кр">0 ORDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC)

После исправления tdf#144340 первый и второй работают в Cyanopica4 без нареканий, а третий виснет.

Но что Вы подразумевали под "на моей дополненной демке"? Там (во встроенной базе) только одна таблица "Months".
С уважением,
Михаил Каганский

Kadet

Цитата: mikekaganski от  7 сентября 2021, 09:16Но что Вы подразумевали под "на моей дополненной демке"? Там (во встроенной базе) только одна таблица "Months".
Я наверное, не правильно выразился или Вы меня не правильно поняли.
Эти запросы я просил попробовать в Cyanopica4. Естественно в демке таких таблиц нет.

А демку я вообще просил проверить с вашим плагином. В посте # 148 помимо картинок в самом верху леит zip-архив, в котором лежать изменённая демка со встроенной и демка с выделенной базой. Вот встроенную я и просил проверить с Вашим плагином.

Kadet

Цитата: economist от  5 сентября 2021, 14:48Лично для меня эта ветка стала хорошим сигналом не использовать FB Embed движок в Base ни для каких целей, уж больно много странностей вылазит по факту.
Мне кажется, что Вы сравниваете не сравнимые вещи, и на этом основании делаете неправильные выводы по поводу FB.
В этой ветке изначально было сказано, что проблема в новой версии LO возникла ТОЛЬКО во встроенной БД. А Вы сравниваете встроенную БД с выделенной SQLite, которая по-умолчанию выделенная и никак не может быть встроенной.
А с выделенной и с FB - никаких проблем нет. Великолепно работает. О чём неоднократно было заявлено.

Поэтому, не стоит грешить на FB. Тут проблемы другого характера - взаимоотношения между встроенными строктурами Base косячат.

mikekaganski

#172
Цитата: mikekaganski от  7 сентября 2021, 09:16После исправления tdf#144340 первый и второй работают в Cyanopica4 без нареканий, а третий виснет.

На самом деле третий тоже прекрасно отрабатывает, а зависает при попытке показать его в таблице результатов запроса. Запрос возвращает BLOB, в котором больше 50000 байт, большинство из которых нулевые байты ... баг, наверное, но если честно, я даже не знаю, как оно отработает на неотладочной версии - может быть, вполне шустро. А у меня просто терпения не хватает дождаться.

EDIT:
Проверил на 7.1.0.4 (релизной, не отладочной). Третий запрос тоже надолго зависает при показе. Так что по итогу - в исправленной версии всё работает теперь не хуже, как в 7.1.
С уважением,
Михаил Каганский

Kadet

Цитата: mikekaganski от  7 сентября 2021, 13:56На самом деле третий тоже прекрасно отрабатывает
Третий запрос, да... Возможно я с ним погорячился. Он делает выборку из таблицы в более 500 записей, и всё это должен записать в виде одной строки. Хотя... что такое 500 записей по 5-11 символов? Максимум 5000 символов... плюс разделители - пусть 500шт. - 5500 символов... Чай не "Война и мир", таки... не так уж и много.
Но, видимо, сляпывание из отдельных записей одной строки сама по себе процедура не быстрая.

mikekaganski

Цитата: Kadet от 10 сентября 2021, 07:05
Цитата: mikekaganski от  7 сентября 2021, 13:56На самом деле третий тоже прекрасно отрабатывает
Третий запрос, да... Возможно я с ним погорячился.

Это был tdf#120129. Исправлено. Проблема, как я уже писал, была не в запросе, а в отрисовке результата, который содержал нулевые байты, ставящие в тупик отрисовку текста.
С уважением,
Михаил Каганский

economist

#175
Цитата: Kadet от  7 сентября 2021, 12:45сравниваете встроенную БД с выделенной SQLite, которая по-умолчанию выделенная и никак не может быть встроенной.

В том-то и дело что после копирования в папку LO Portable всего 2-х готовых файлов - SQLite, по-сути, становится "встроенной", т.е. готова к копированию/скачиванию всей LO-папкой куда угодно. В таком LO легко подключиться к файлу БД из LAN и получить быструю "мало-пользовательскую" БД. Пути  к вашим БД из "демок" - уже прописаны, БД "зарегистрированы", инструкции по подключению не требуется вовсе.

При этом скорость, простота и удобство без-серверной, без-типовой SQLite, имхо, намного выше чем у HSQLDB/FireBird_Embed. Опциональное использование встроенного Python для больших транзакций - делает SQLite почти "серверной" (задействуется WAL-журналирование, которое убирает конфликат записи вида "четверо читают или один пишет"). В итоге SQLite по скорости легко "делает" MS Access, в поисках замены которого сюда на Форум частенько заходят. Для демок с одной кнопкой  "Скачать и Запустить" - самое то. Ну а мы такое используем в "проде", на уровне отделов. Скорости хватает, а отсутствие необходимости регить юзеров, конфигить сервер с MySQL/PostgreSQL/FireBird_Server и общаться с IT-шниками - приводит к тому что некоторые проекты "автоматизации снизу", целиком на базе СПО, сделанные без спросу, - выстреливают быстро, с большим профитом, без затрат и "откатов". Для значительной (имхо, это 70%) части предприятий наш LibreOffice с "плюшками" - это единственный способ что-то реально автоматизировать у себя из рутины.

Ежли это "самовозгорание" не происходит - через год-два придет беда "эффективный менеджер", притащит "своего" консалтера+вендора, они вместе запудрят мозги владельцам и фирма, потратив пару лямов - получит "еще одну непонятно кому нужную программу" (в дополнение к 1С/CRM/EDM/Excel/etc).
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

mikekaganski

#176
В общем, вот синопсис багов, затронутых в теме.

1. Связанные с Firebird.

Цитата: Kadet от 27 августа 2021, 11:22
В общем, так. При получении списка строковых значений путём простого запроса, допустим такого:
oSql = "SELECT list(""Марка"",'"";""') FROM ""МАРКА"""
Встроенная БД выдаёт список значений которые после самих данных заполнены какими-то невидимыми символами.
Цитата: mikekaganski от 27 августа 2021, 12:42
Явный баг - доступ к неинициализированной памяти или unchecked bounds - обязательно нужен багрепорт.

Это был баг обработки CLOB (текстовых BLOB) в драйвере SDBC Firebird - tdf#120129. Исправлен сегодня.
Только теперь можно сказать, что
Цитата: Kadet от  1 сентября 2021, 11:43
А list, оказывается, стал нормально работать

Цитата: Kadet от 31 августа 2021, 16:57
Область поисков сужается.
Простейшие запросы:
SELECT "Размер" FROM "РАЗМЕРЫ"

И он же с группировкой:
SELECT "Размер" FROM "РАЗМЕРЫ" GROUP BY "РАЗМЕРЫ"."Размер"

Дают следующие результаты. (вложения).
Цитата: mikekaganski от 31 августа 2021, 19:30
Цитата: mikekaganski от 31 августа 2021, 17:17
Найс! Воспроизводится на Вашей Cyanopica4. Можно попробовать найти проблему.

Ощущение, что это - следствие первоначального

Цитата: Kadet от 27 августа 2021, 11:22Встроенная БД выдаёт список значений которые после самих данных заполнены какими-то невидимыми символами.

Я ошибался в том, что эти вещи связаны; это был tdf#144340, связанный с обновлением Firebird до релиза 3.0.7 в ЛО 7.2; при этом свойства конфигуратора FB, в связке с хаком ЛО для его интеграции, привели к неправильному определению размера типа long long под Windows, и как следствие - разрушению данных в памяти при сортировке в Firebird. Исправлено в понедельник.

В процессе работы с ним я написал tdf#144230 и "исправил" его - но по факту то исправление оказалось паллиативом, и в свете вышеуказанного фикса уже не актуально. Однако убирать его не буду, оно не мешает.

Цитата: mikekaganski от 30 августа 2021, 09:58
Тестируя базу из ответа 45 в 7.2.1.1 и в мастере под Win10, я вижу, во-первых, зависание намертво - связанное, по-видимому, с багом в Firebird (жду ответа на комментарий здесь)

Это был tdf#144172, связанный с возможностью запуска нескольких встроенных движков FB, настроенных на использование разных расположений служебных директорий, одновременно на системе - например, из нескольких параллельно установленных ЛО, или из ЛО + из ванильного FB. Присутствовал изначально; виден только тогда, когда пытаешься использовать такие движки одновременно. Это была моя локальная проблема, исправленная неделю назад.

Дополнительно внесены некоторые внутренние изменения в код интеграции FB, которые не исправляют никаких ошибок, а, например, помогают в отладке, устраняют ненужные повторные чтения одних и тех же данных или используют более эффективные структуры данных.

И ещё работа над этими проблемами инициировала некоторые (хоть и небольшие) изменения в самом Firebird: раз, два (в работе).

2. Не связанные с Firebird

Цитата: rami от 28 августа 2021, 21:31
Я вот что заметил: если из Calc запустить макрос, а в другом модуле этой же библиотеки (пользовательской) будет ошибка, то в LibreOffice 7.2.0.3 виснет офис, а в LibreOffice 5.0.6 сообщает об ошибке без зависаний.

Это был tdf#144183 (регрессия в 7.2), исправлен 31 августа.

Резюмирую: оччччень продуктивная тема получилась. Спасибо Kadet!
С уважением,
Михаил Каганский

Kadet

Спасибо за исправления и помощь!

Надеюсь всё это войдёт в ближайшую версию LO.

mikekaganski

Цитата: Kadet от 14 сентября 2021, 12:38Надеюсь всё это войдёт в ближайшую версию LO.

Нет, не всё в ближайшую. ЕМНИП что-то только в 7.2.2.
С уважением,
Михаил Каганский