[ANN] Furwall - prevents unauthorized access

[Alex Dmitriev]

Всем привет

Вот такой концепт наваял для ограничения прав досутпа к объектам:

http://github.com/dekart/furwall/tree/master

Работает в связке с acl_system2. Буду рад конструктивной критике.

--
Ruby on Rails Developer
Skype: rene-dekart
Email/Jabber/GTalk: rene....@gmail.com
Blog: http://www.html-blog.ru

[Oleg Andreev]

On 01.11.2008, at 13:12, Alex Dmitriev wrote:

> Буду рад конструктивной критике.

Конструктивно тебя покритикуют другие
персонажи, это скучно -)

Я неконструктивно скажу:

1. Лолкэт и назание в ридми прикольные.
2. Английский язык следует тренировать.
Хотя бы перечитывать писанину на
наличие опечаток, которых там, как
сказок шехерезады, ровно тысяча и одна
штука.
3. Вот такой код: "admin | (product_manager & :pending)"
или "admin | .owner" я бы непозволил писать в
своем проекте. Потому что это ненужное изобретение недоязыка в языке (htt
p://oleganza.tumblr.com/post/55426373/respect-the-language)
Это относится, наверное, больше к
acl_system2, чем к шерстеволу.

В целом, мне acl_system2 как-то не нужен, под
задачу сейчас не подходит.

А за такое:

<% restrict_to "(admin | moderator) & !blacklist" do %>
<%= link_to "Admin & Moderator only link", :action =>'foo' %>
<% end %>

нужно вырывать ноги. Потому что в их
(caboose) имплементации при каждом
рендеринге вью будет парсится строка
правил. Это исправляется
генерированием кода в какой-нить метод
с именем == хешу строки правил. А их
метод process(logicstring, context) не супербыстрый.
И всех этих проблем бы не было, если бы
правила задавались лямбдой:

proc {|r| (r.admin || r.moderator) && !r.blacklist }


Кстати, оказывается, в MRI не все так
плохо с регэкспами:

5.times{ puts "literal string".object_id }
3718630
3718610
3718590
3718570
3718550

5.times{ puts /literal regexp/.object_id }
3713210
3713210
3713210
3713210
3713210

[Yaroslav Markin]

2008/11/1 Oleg Andreev <oleg...@gmail.com>

Потому что это ненужное изобретение недоязыка в языке (htt
p://oleganza.tumblr.com/post/55426373/respect-the-language)

продолжая оффтопик, кто-нибудь смотрел код ambition? вот где жесть так жесть. 

--
Yaroslav Markin

[Alex Dmitriev]

1 ноября 2008 г. 16:09 пользователь Oleg Andreev <oleg...@gmail.com> написал:

1. Лолкэт и назание в ридми прикольные.
2. Английский язык следует тренировать.
Хотя бы перечитывать писанину на
наличие опечаток, которых там, как
сказок шехерезады, ровно тысяча и одна
штука.

Перечитаю.
 

3. Вот такой код: "admin | (product_manager & :pending)"
или "admin | .owner" я бы непозволил писать в
своем проекте. Потому что это ненужное изобретение недоязыка в языке (htt
p://oleganza.tumblr.com/post/55426373/respect-the-language)
Это относится, наверное, больше к
acl_system2, чем к шерстеволу.

В acl_system2 правила пишутся просто как "admin | product_manager", все двоеточия и точки - мои изыскания. Критикуя - предлагай. Как избавиться от недоязыка в языке? С учетом того, конечно, что правила доступа должны храниться в строковом поле записи БД и быть редактируемыми не-админами и не-программистами. И чтобы обойтись без eval.

нужно вырывать ноги. Потому что в их
(caboose) имплементации при каждом
рендеринге вью будет парсится строка
правил. Это исправляется
генерированием кода в какой-нить метод
с именем == хешу строки правил. А их
метод process(logicstring, context) не супербыстрый.

Кстати, надо взять на заметку, возможно стоит дописать плагин чтобы "все в одном", включив и переработав код acl_system2. Однако, опять же, серьезный вопрос - насколько оправдано хэширование если правила хранятся в БД? Потенциально их ведь может быть тьма - раздача прав идет как для моделей целиком, так и для отдельных экземляров.

И всех этих проблем бы не было, если бы
правила задавались лямбдой:

proc {|r| (r.admin || r.moderator) && !r.blacklist }

См. комментарий к п. 3

[Max Lapshin]

Я немножко глянул, но сразу не понял: ты сможешь этой штукой ограничить разным пользователям
возможность апдейтить те или иные атрибуты?

[Alex Dmitriev]

Проверка прав делается внутри контроллера, поэтому можно сделать например так:

1) Создаем правило для разграничения прав доступа к группам аттрибутов:

edit_group_1: "admin | group_1"
edit_group_2: "admin | group_2"

2) В контроллере:

if object_permit(@my_object, :edit_group_1)
  @my_object.set_group(1)
else

1 ноября 2008 г. 19:19 пользователь Max Lapshin <max.l...@gmail.com> написал:

Я немножко глянул, но сразу не понял: ты сможешь этой штукой ограничить разным пользователям
возможность апдейтить те или иные атрибуты?

[Alex Dmitriev]

Проверка прав делается внутри контроллера, поэтому можно сделать например так:

1) Создаем правило для разграничения прав доступа к группам аттрибутов:

edit_group_1: "admin | group_1"
edit_group_2: "admin | group_2"

2) В контроллере:

if object_permit(@my_object, :edit_group_1)

  @my_object.group = 1
else
  @my_object.group = 2
end

3) В модели

attr_accessible :group

def before_validate
  case self.group
  when 1:
     self.errors.add(:attribute_1, "cannot be changed") if self.attribute_1_changed?
  when 2:
     self.errors.add(:attribute_2, "cannot be changed") if self.attribute_2_changed?
  end
end

1 ноября 2008 г. 20:39 пользователь Alex Dmitriev <m...@html-blog.ru> написал:

[Max Lapshin]

ясно