Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А что будем считать за единицу версионности? (символ, строка, абзац, токен в терминах грамматики языка разметки и т.п.)
Хз. Тут надо думать.
Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
KV>>А что будем считать за единицу версионности? (символ, строка, абзац, токен в терминах грамматики языка разметки и т.п.)
VD>Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.
Да лаааадно... МедиаВики отлично работает с построчными диффами на уровне статей. А она на пехапе написана.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Реализация диффа на немерле есть у меня Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.
Здравствуйте, catbert, Вы писали:
VD>>Возможно сначала нудно сравнивать разметку, а уже потом внутри нее текст. Вообще, нужно смотреть на поведение других вик.
C>Да лаааадно... МедиаВики отлично работает с построчными диффами на уровне статей. А она на пехапе написана.
Что значит "с построчными"? Там ведь сравнивается текст, не текст с разметкой. Значит они сравнивают не просто текст.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что значит "с построчными"? Там ведь сравнивается текст, не текст с разметкой. Значит они сравнивают не просто текст.
Здравствуйте, IT, Вы писали:
IT>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.
Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.
Здравствуйте, Ziaw, Вы писали:
Z>А чему противоречат диффы текста с разметкой?
А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.
В прочем, я вики никогда не делал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>А чему противоречат диффы текста с разметкой?
VD>А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.
С разметкой и выводить. К примеру вот так выглядит дифф в википедии.
Здравствуйте, Ziaw, Вы писали:
VD>>А как ты их пользователю выводить собираешься? К тому же алгоритмы не будут в силах понять, что код форматирования относится к текущему тексту или идущему ниже. Будут накладки. Если сначала построить структуру документа, а потом сравнить внутри нее отдельный текст, то получится куда лучше.
Z>С разметкой и выводить. К примеру вот так выглядит дифф в википедии.
Можно конечно и так. Так значительно проще реализовать. Хотя я бы предпочел сравнивать рендеренный результат, а не код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
IT>>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.
Z>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
Можно подумать насчёт чего-то вроде Access Control ID и снабжать им ресурсы, а уже его вязать с ACL.
Z>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом. Z>Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.
Именно. У нас есть две большие группы, которые покрывают 99% запросов сейчас, это анонимы и обычные юзеры. Для этих групп должны формироваться отдельные фильтры в запросах.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Можно подумать насчёт чего-то вроде Access Control ID и снабжать им ресурсы, а уже его вязать с ACL.
Да мы вроде бы об этом уже думали и пришли к выводу что так и нужно делать. Точнее ACL должен быть таблицей с этим самым ID. А ресурсы должны хранить этот ID.
Z>>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом. Z>>Но если ввести ограничения, например доступ на чтение открыт для всех (спец случаи как-то захардкодить) — сложные проверки останутся только при изменениях, а это уже вполне посильная нагрузка.
IT>Именно. У нас есть две большие группы, которые покрывают 99% запросов сейчас, это анонимы и обычные юзеры. Для этих групп должны формироваться отдельные фильтры в запросах.
А зачем отдельные? Если принять схему с ACL и его ID, то все получится автоматом. Просто у юзеров и анонимов будет ровно по одному ACL-у в списке.
Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А зачем отдельные? Если принять схему с ACL и его ID, то все получится автоматом. Просто у юзеров и анонимов будет ровно по одному ACL-у в списке.
Точно. А раз так, то из фильтра можно убрать таблицу с ролями, таблицу ACE (Role/ACL), а для анонимов возможно и саму ACL, тогда для анонимов фильтрация сведётся к простому условию в WHERE целевых таблиц. Для юзеров тоже можно дооптимизироваться до WHERE AclID IN (..., ...)
VD>Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).
Бан большее имеет отношения к роли, чем к доступу к ресурсам. Я бы сюда это не мешал.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Точно. А раз так, то из фильтра можно убрать таблицу с ролями, таблицу ACE (Role/ACL), а для анонимов возможно и саму ACL, тогда для анонимов фильтрация сведётся к простому условию в WHERE целевых таблиц. Для юзеров тоже можно дооптимизироваться до WHERE AclID IN (..., ...)
Думаю, что для всех можно "WHERE AclID IN (...)" использовать. SQL-сервер не идиоты писали. Если в in будет одно или два значения, то его заоптимизируют. На крайняк добавим трансформацию "WHERE AclID IN (X, Y)" в "WHERE AclID = X or AclID = Y". Причем прямо в БЛТулкике .
VD>>Еще вопрос в забаненных юзерах. Или в отрицательных ACL-ах (если прнять такую схему и реализовать забанных через нее).
IT>Бан большее имеет отношения к роли, чем к доступу к ресурсам. Я бы сюда это не мешал.
А я бы мешал. В прочем, это уже детали. Я только не понял нафиг нам тут какие-то роли? В прочем группы, роли... лишь бы в печь не ставили...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли).
А MAC в чистом виде практически и не используется (см. ниже).
IT>Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.
Давай я пофантазирую на тему того, каким мог бы быть контроль доступа на RSDN (на базе гибрида MAC и ролевого доступа), а вы с Владом решите, почему он не подходит?
В первую очередь, определимся с тем, что является субъектами и объектами доступа. Субъектами будут являться пользовательские сессии, а отнюдь не пользователи, как здесь раньше обсуждалось. Тому есть несколько причин, чтобы не растекаться мыслью я их опущу и, если надо распишу позже. С объектами же все несколько сложнее. Дело в том, что обеспечить однородность объектов доступа в случае данного сайта крайне тяжело. Во-первых, это будут те самые "ноды", о которых писал Влад на тимовском форуме и которые тут
я назвал "сообщениями". Во-вторых, это будут разделы сайта не относящиеся к нодам, такие как админ-интерфейс (то, что не удасться интегрировать в основное представление страниц сайта, например — список забаненных), профиль пользователя и т.п. В приципе, ничто не мешает сделать это все "нодами" и это было бы идеально с т.з. безопасности, но и являлось бы весьма серьезным решением с т.з. архитектуры всего сайта, поэтому тут я хз, надо обсуждать. Далее, я буду исходить из того, что сие серьезное решение места не имеет и у нас объекты доступа разнородны.
В MAC принятие решения о предоставлении доступа или отказе принимается следующим образом: каждый субъект и объект доступа снабжается т.н. меткой безопасности состоящей из двух частей: уровня конфиденциальности ("конфиденциально", "публично доступно" и т.п.) и категорий ("проект А", "проект Б" и т.п.). При принятии решения о доступе к чему либо, метки субъекта и объекта сравниваются следующим образом: уровень конфиденциальности субъекта (его уровень допуска) должен быть не ниже чем соответствующий уровень объекта, а список категорий у субъекта должен ключать в себя весь список категорий объекта. Из этого следует основной недостаток чистого MAC'а — он определяет только возможность доступа (и позволяет это делать очень дешево с т.з. производительности), но не конкретизирует перечень действий, которые может совершить субъект с объектом.
Поэтому, мы скомбинируем MAC с одной из распространенных моделей, решающих данную проблему. Таких моделей две: DAC и RBAC. Первая — дискреционная модель, подразумевает такое понятие как "владелец объекта доступа", предоставляя ему ничем не ограниченные права в т.ч. и на определение прав доступа к объекту. В DAC субъекты снабжаются листами доступа (ACL) в которых указано какие именно субъекты, могут совершать с данным объектом те или иные действия. Это именно то, что реализовано в NT и что вы здесь обсуждали. Проблема в том, что в ASP.NET уже реализована (как справедливо заметил IT, весьма прилично) модель доступа, отличная от DAC. Это — RBAC, ролевая модель, в которой уровень доступа определяется членством субъекта в какой-либо группе (т.е. принадлежностью к роли), соответственно у объектов понятие ACL отсутствует в принципе, их заменяет либо централизованный список разрешений для каждой из групп, либо данный список хардкодится прямо в систему, что является вариантом малоприемлемым, но тем не менее. Посему, нужно либо вообще отказываться от уже реализованного в ASP.NET и писать свой провайдер авторизации (я пробовал — это ни с чем не сравнимый гемморой), либо сэмулировать DAC на RBAC'е, что навскидку, является куда менее гемморным занятием.
Таким образом, мы будем использовать MAC как дешевый способ определить может ли вообще субъект осуществлять тот или иной доступ, и, если может, то будем дополнительно использовать DAC over RBAC для определения, какой именно.
Сначала MAC: все метки безопасности, которыми мы снабдим и субъектов и объектов будут содержать один из уровней конфиденциальности:
Форум
Список тем форума
Тема форума
Сообщение форума
Статья вики
Комментарий к статье вики
и т.п.
Т.о. если аноним (имеющий уровень конфиденциальности "0") запросит тему из тимовского форума (имеющую уровень конфиденциальности "2"), то получит отлуп после простого сравнения двух целых чисел. Другой пример: аноним, даже прошедший проверку уровня конфиденциальности, но не имеющий в списке категорий элементов "Статья вики" и "Комментарий...", получит отлуп, запросив статью из вики, после сравнения списка айдишников категорий его метки и списка айдишников категорий метки этой статьи.
Каким боком мы сюда притянем RBAC? Очень просто — наши уровни конфиденциальности из MAC будут одновременно ролями в терминах RBAC. А категории, айдишники которых содержатся в метках безопасности, будут включать в себя не только название, но и ACL (либо его айдишник), в котором будет перечислено какая из групп какие действия может совершить с объектом данной категории
Остались нерешенными два вопроса: наследование прав объектами и роль "владелец" объекта. Наследование может быть реализовано как копированием метки доступа родителя, так и хранением айдишника метки родителя. И в том и другом случае наследоваться они должны по следующим правилам:
1. Дочерний уровень конфиденциальности всегда замещается родительским
2. Списки категорий родителя и дочки (а следовательно и их ACL'и) объединяются
Копирование метки доступа, IMHO предпочтительнее, т.к. существенно повысит производительность (не нужно будет дополнительно выгребать метку родителя и объединять с дочерней), но расставит грабли, связанные с переносом объекта доступа в другую иерархию и актуализацию метки из-за изменения метки родителя.
"Владелец объекта" реализуется, например, следующим образом: вводим новую одноименную роль (а следовательно и уровень конфиденциальности со значением 5, т.е. самым высоким), не присваиваем ее никому из субъектов и объектов, но заводим таблицу, хранящую список владельцев каждого из объектов. Перед тем, как проверять возможность доступа в MAC'е, делаем выборку из этой таблицы и если текущий субъект является владельцем запрошенного объекта, то меняем в обоих метках (не в базе, разумеется) уровень конфидециальности на 5-ый и далее работаем так, как было описано выше. Конечно, для каждой из категорий классификации дожен быть заранее прописан ACL для роли "Владелец".
Ну вот, как-то так
P.S: Бонусная мысль, спорная, но IMHO интересная. Львиной доли проверок можно избежать, если вынести их в отдельный слой (Access Control Layer) в виде эдакого generic-слоя и конкретизировав его в момент создания сессии меткой безопасности текущего субъекта, скомпилировать в отдельную сборку, через которую и будет осуществляться доступ ко всем ресурсам сайта в рамках этой сессии. Если это интересно, могу раскрыть мысль шире, но позже, ибо уже валюсь с ног
Здравствуйте, VladD2, Вы писали:
VD>Так что выбор только из MS SQL Server или файлами. Отдельная СУБД тоже не особо нужна. Достаточно хранить данные в отдельной таблице. Если что можно их средствами SQL-сервера вынести в отдельную файловую группу.
Если SQL Server 2008 и выше, то выбор делать не нужно, есть Filestream.
Здравствуйте, Ziaw, Вы писали:
Z>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем.
Можно еще озаботиться убиранием дублированных ACL, для этого каждому ACL ставится в однозначное соответствие строка и при попытке добавить новый ACL в базу ищется запись с таким "ключом".
Если цеплять права не на отдельных пользователей, а на группы, то различных ACL наберется десятка два.
Z>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом.
Неправда, есть private кеширование, когда документ кешируется только на клиентской стороне, главное last modified и etag выставлять.
А на сервере документы кешируются точно также, только дополнительная проверка доступа происходит при обращении.
Здравствуйте, gandjustas, Вы писали:
Z>>Если использовать наследование, то не все так плохо. Т.е. в каждом сообщении появляется ссылка на acl предка. Т.е. размер базы увеличится на количество различных ACL плюс на размер ключа в ACL для каждого сообщения. Не так критично вобщем. G>Можно еще озаботиться убиранием дублированных ACL, для этого каждому ACL ставится в однозначное соответствие строка и при попытке добавить новый ACL в базу ищется запись с таким "ключом". G>Если цеплять права не на отдельных пользователей, а на группы, то различных ACL наберется десятка два.
Да, тогда перед запросом из acl будут выбраны те, которые разрешают доступ (выборку можно свести к очень быстрой операции) и сам фильтр сведется к acl_id in (). Так как большинство запросов на чтение идут с одним набором — есть хорошая вероятность, что процентов 90% запросов лягут в кеш сервера.
Z>>Главная загвоздка будет на выборках. Если их результат начнет зависеть от пользователя — все кеширования сразу пойдут лесом. G>Неправда, есть private кеширование, когда документ кешируется только на клиентской стороне, главное last modified и etag выставлять. G>А на сервере документы кешируются точно также, только дополнительная проверка доступа происходит при обращении.
Кеширование на клиентской стороне тут конечно поможет, особенно на конкретные страницы. Проблема была не перегрузить сервер сложными запросами при показе списков страниц (то, что в правом верхнем фрейме), у этих списков last modified вычисляется ничуть не дешевле вытаскивания самого списка. Впрочем отвечать not modified после вытаскивания тоже полезно. Как для экономии исходящего канала, так и для большей отзывчивости интерфейса.
Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.
.
Если нам не помогут, то мы тоже никого не пощадим.
