Neo4j gem - предпочтительный метод для работы с административными отношениями

Это то, о чем я много думаю и что само по себе достойно записи в блоге или скринкаста. У меня есть свои лучшие практики, но я бы не сказал, что это ЛУЧШИЙ способ сделать это. Может быть что-то, что я не учел. Но вот с чем я работаю.

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

Вообще говоря, я стараюсь избегать создания дополнительных отношений для таких вещей, как административная информация, когда я могу использовать существующие отношения. Я остановился на двух практиках:

• Во-первых, вы можете получить базовый вариант «имеет доступ/не имеет доступа», следуя по пути к объекту, как показано в обновлении. Если вы хотите ограничить список только событиями друзей, сделайте что-то вроде этого:

  friend.events.query_as(:event).match.all_the_rest_of_your_chain

Начав за друга, вы будете возвращать только события, с которыми он связан. Теперь, если вам нужны только события, которыми они владеют...

• Вы можете использовать целочисленное свойство, которое я обычно называю своим score, в отношении, чтобы представить уровень доступа этого пользователя к нему. Целые числа — это круто, потому что вы можете установить соглашение о подсчете очков, 0 — нет прав, 50 — редактор, 99 — администратор — что-то в этом роде — а затем сказать «где rel.score > {admin_score}», и вы получите только те отношения, где они имеют правильный уровень доступа или выше. Это было бы что-то вроде...

  friend.events(:e, :rel).where("rel.score > {privileged_score}").params(privileged_score: 0).continue_your_chain

Обратите внимание, что мы должны использовать строку и установить собственный параметр, потому что where в QueryProxy будет нацелен на самый последний узел, мы не можем сделать .where(rel: { score: privileged_score }). (Кстати, я планирую как можно скорее добавить метод rel_where, чтобы справиться с этим.)

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

Я бы начал там. Когда вы задаете более сложные вопросы авторизации, такие как «Сопоставьте события, в которых пользователь владеет событием ИЛИ владеет местом, где происходит событие, включите привилегированную информацию, но количество привилегированной информации зависит от того, какие из этих элементов принадлежат ему... и а если и то и другое?" есть еще некоторые соображения, но мы можем поговорить об этом в другой раз. ;-)

Вы также можете прочитать об области действия на странице https://github.com/neo4jrb/neo4j/wiki/Search-and-Scope. В текущем выпуске он немного грубоват и содержит ошибки, но у Брайана есть открытый PR для обновления, которое делает это намного лучше. Вы сможете написать собственный метод:

def privileged_events(score = 0
  events(:e, :rel).where("rel.score = {rel_score}").params(rel_score: score) 
end

А затем сделайте что-то вроде user.privileged_events.more_query_chain_methods, чтобы части запросов можно было использовать повторно. Нам нужно исправить одну спецификацию, это просто проблема с двойником, и она будет объединена с мастером. У нас должен быть релиз-кандидат 4.0 (если мы вообще думаем, что RC необходим) через несколько дней.

Еще одно...

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

<%= @events.each do |event| %>
  <% if @event.users(:u, :rel).where("rel.score = {admin_score}").params(admin_score: 99).include?(current_user) %>
    # do stuff
  <% end %>
<% end %>

Этот вызов include? будет обрабатываться на стороне сервера и просто возвращать логическое значение, это не очень дорого.

Я не думаю, что он идеален — он определенно менее эффективен — но его намного проще построить. Вы всегда можете провести рефакторинг; черт возьми, вы должны ожидать, что в какой-то момент вам все равно придется проводить рефакторинг.