username1565
commented
3 years ago Из этих строчек: https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Captcha/Captcha.cs#L336 https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Captcha/Captcha.cs#L344 https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Captcha/Captcha.cs#L352
Очевидно, что для POW и каптчи - считается какой-то - отдельный хэш.
Этот отдельный хэш, это не хэш поста (PostHash).
Он используется для генерации/валидации POW, а также отчасти (пару байт) - задаёт индекс каптчи.
Хэш поста, включает POW и SIGN теги, внутри message, формирующиеся уже после решения POW и каптчи:
https://github.com/username1565/nanoboard/blob/8f0edd8d02b9f680f7ce1f70ddd29b8f7c367110/nanodb.exe-source/Database/PostsValidator.cs#L49
Рассчет этого, отдельного хэша, ускоряется вырезанием подписи (решённая каптча),
так как подпись - изменяет хэш, если её не вырезать,
и заменой тега xmg на хэш от вложения внутри нанопоста.
То же самое, следовало бы сделать и для аттачей в теге [file][/file],
в результате чего, некоторые посты, содержащие тег [file] внутри,
они перестанут проходить валидацию по предыдущей схеме.
Поскольку их всего несколько, не вижу в этом проблемы, однако старые версии наноборды не будут это делать, без апдейта. Поэтому, лучше, наверное, принебречь этим ускорением, и считать хэши чуть медленнее.
Вообще, следовало бы, наверное, сохранять аттачи отдельно, как отдельные нанопосты, а внутрь нанопостов, просто ложить хэши их. Тогда, нанопосты, могли бы иметь намного меньший размер, и несколько аттачей могло бы использоваться во множестве постов, без прикрепления их самих - только хэш уже имеющегося аттача.
Karasiq
После добавления тега
[file][/file]для аттачей разных типов, POW срабатывает медленно, так как файлы-атачи не обрезаются.https://github.com/username1565/nanoboard/blob/82f7595e3e875d391b5a847308581a41b9f650d6/nanodb.exe-source/Captcha/Captcha.cs#L394 https://github.com/username1565/nanoboard/blob/82f7595e3e875d391b5a847308581a41b9f650d6/nanodb.exe-source/Captcha/Captcha.cs#L556
Надо будет реализовать некий метод ExceptFile, для вырезания файлов-аттачей из поста, и замену base64 на hash, для скорейшего хэширования поста, как реализовано в методе ExceptXmg: https://github.com/username1565/nanoboard/blob/82f7595e3e875d391b5a847308581a41b9f650d6/nanodb.exe-source/Captcha/Captcha.cs#L376-L384
Однако, тогда, сменится хэш некоторых постов, где аттачи уже прицеплены, и эти посты не пройдут, ни bypassValidation, ни fullValidation (validation of captcha-answer, by sign-value).
Значит, надо будет либо переписать эти посты, либо для сохранения обратной совместимости, надо будет, делать ExceptFile не для всех постов, а для постов, впощенных уже после даты этого апдейта, изменяющего фундаментальные и основополагающие принципы функционирования ядра наноборды. Дату нанопостов можно брать из
[g][/g]-тега, однако если bypassValidation=true, то нанопост может иметь упрощенный формат: PostHash = (replyTo+Message) безо всяких дат в[g]-теге, и тут уже будет сложно детектить старые посты и новые.Поэтому, наверняка, следовало бы сделать список имеющихся нанопостов и вхардкодить их, в виде списка или словаря. Или просто сделать вхардкодить список хэшей, которые валидны, и не просчитывать хэши для постов с этими хэшами. Однако, привязывать код наноборды к контенту её базы данных, не очень целесообразно, поэтому лучше, наверное, никакие хэши и вовсе не хардкодить внутри кода, а сделать всё как-то по-другому.
Например, замнув список хэшей на кастомный JSON-файл или на значение списка хэшей, в JSON-конфиге.