Ну, это не совсем так, кое-что есть. Например, голосование с возможностью отмены и переголосования. Это позволит человеку, находящемуся под давлением, сделать вид, что он проголосовал, после чего, когда опасность отступила, отменить и изменить свой голос.
ну вот по мере сил и понимания, сделали опенсорс, если я правильно трактую действия разработчиков. Дальше — наша очередь, разбираться что они там наваяли
Django-Guardian ориентируется на специализированную модель объекта прав, явным образом связывающую с помощью Generic PK пользователя с каждым объектом, для которого нужно установить права доступа.
Django-Access определяет функциональные права доступа в соответствие с правилами, устанавливающими связь между объектами для принятия решения о том, какие действия может произвести данный пользователь с данным объектом.
Например, в рассмотренном примере, в случае Django-Guardian, чтобы установить, что пользователь 'test' имеет право изменять объект Vehicle '1234' принадлежащий данному проекту, нужно будет создать объект UserObjectPermission, связывающий 'test' с 1234'. В то же время для Django-Access с определенными в примере правилами доступа, сам факт того, что 'test' и '1234' принадлежат одному и тому же проекту, уже достаточен для того, чтобы определить порядок доступа.
Таким образом, функциональные связи, уже существующие в проекте, становятся достаточны (или почти достаточны) для того, чтобы установить порядок доступа, в то время как Django-Guardian требует создания явной связки между пользователем и объектом модели в специальной таблице.
В этом смысле, Django-Access больше похож на пакет Django Permissions, но у последнего есть другие проблемы, которые решены в Django-Access.
1) Не совсем понимаю, как здесь работал бы Generic FK. Generic FK не то чтобы медленнее, он просто неудобный, поэтому я стараюсь пользоваться им как можно реже. Здесь ведь и Generic FK в принципе, не нужен, достаточно общего абстрактного предка, правда там механизм объявления related_name какой-то недоделанный. Можно было бы сделать предка неабстрактным, но практика показывает что вот такое решение как раз действительно медленнее: многие запросы в развитом приложении будут пересекать границы JOIN между предком и наследником. Поскольку это туториал, хотелось обойтись без всех этих сложностей, проще всего было сделать ссылку в каждом классе, который ее требовал.
2) Можно и так, несущественно. Фокус с `INSTALLED_APPS` уже отработан на практике, а с ready hook надо будет прикинуть, может быть даже сделать автоматическую подгрузку правил.
… при этом все удобство заканчивается тогда, когда пользователь забывает пресловутый «сильный пароль» от менеджера паролей, а вся безопасность — когда он же (во избежание вышеописанного) записывает злосчастный «сильный пароль» от менеджера паролей на подставке для монитора…
Попытки разрешить противоречие между безопасностью и удобством с помощью дополнительных инструментов имхо приводит скорее не к поставленной цели, а к возникновению (или усилению) новых, еще не исследованных рисков, которые не заметны на фоне новизны применяемого инструмента.
Так например, FaceID и системы с отпечатком пальца оказываются подвержены подделке с помощью моделирования, менеджер паролей может быть взломан или подменен, а мастер-пароль — забыт или незаметно скомпрометирован, сохраненный локально ключ доступа — украден вирусом, или скачан при временном доступе к физическому хосту со стороны злоумышленника.
Таким образом, кажущаяся удобной защита от одних рисков приводит к возникновению (или усилению) других. Похоже, игра в этом случае таки остается с нулевой суммой, лишь возрастает количество неизвестных.
Плагин уж если делать, так сразу полноценный — с альтернативным защищенным распределенным децентрализованным DNS и распределенной сетью доставки, чтобы вообще больше никогда не зависеть от централизованных сервисов.
Но плагин ведь еще поставить надо. Много ли людей поставили себе friGate?
А описанное решение — для тех, кто поленится не то чтобы плагин поставить, а даже поинтересоваться, что это вдруг сайт перестал отвечать…
Я же написал — штатными. Насчет js — не очень хорошо, когда мидлварь вмешивается в страницу, это и существенно затратнее по ресурсам. Но да, я думал о таком варианте, в принципе, можно даже попробовать избежать вмешательства в страницу, плюс один редирект.
Без куки не получится закрепить домен за агентом, что приведет к быстрому перебору оператором блокировок всего пула доменов второго уровня.
К сожалению, куки имеют ограничение, приводящее к невозможности обмена куками между разными доменами второго уровня. Обмен куками между доменами третьего уровня — возможен.
Не имея возможности обмена куками, мы не сможем (штатными средствами) распознать повторный вход агента оператора блокировок на альтернативный домен и правильным образом редиректить его на его личный URL. Остается только использовать случвйный выбор домена второго уровня, что вероятно, приведет к быстрому исчерпанию пула доменов второго уровня.
открою секрет полишинеля, реестр блокировок имеет ограниченную длину, до которой он уже почти добрался, поэтому его недавно почистили аж вдвое. Адовое количество блокируемых ссылок очень быстро приведет к переполнению реестра.
Написано на "давай-давай" видимо...
Ну, это не совсем так, кое-что есть. Например, голосование с возможностью отмены и переголосования. Это позволит человеку, находящемуся под давлением, сделать вид, что он проголосовал, после чего, когда опасность отступила, отменить и изменить свой голос.
я же специально прямую ссылку на ветку поставил.
Active branches
voting2020
Updated 5 days ago by a-borodenkov
ну вот по мере сил и понимания, сделали опенсорс, если я правильно трактую действия разработчиков. Дальше — наша очередь, разбираться что они там наваяли
да, регистрация — одно из самых уязвимых мест
по ссылке — ветка voting2020 которая видимо, и будет использована нынче
спасибо, очень полезная информация!
пока я так понимаю, что предлагают поверить на слово :) Хотя как мне кажется, есть возможность надавить
Django-Guardian ориентируется на специализированную модель объекта прав, явным образом связывающую с помощью Generic PK пользователя с каждым объектом, для которого нужно установить права доступа.
Django-Access определяет функциональные права доступа в соответствие с правилами, устанавливающими связь между объектами для принятия решения о том, какие действия может произвести данный пользователь с данным объектом.
Например, в рассмотренном примере, в случае Django-Guardian, чтобы установить, что пользователь 'test' имеет право изменять объект Vehicle '1234' принадлежащий данному проекту, нужно будет создать объект
UserObjectPermission, связывающий 'test' с 1234'. В то же время для Django-Access с определенными в примере правилами доступа, сам факт того, что 'test' и '1234' принадлежат одному и тому же проекту, уже достаточен для того, чтобы определить порядок доступа.Таким образом, функциональные связи, уже существующие в проекте, становятся достаточны (или почти достаточны) для того, чтобы установить порядок доступа, в то время как Django-Guardian требует создания явной связки между пользователем и объектом модели в специальной таблице.
В этом смысле,
Django-Accessбольше похож на пакет Django Permissions, но у последнего есть другие проблемы, которые решены вDjango-Access.2) Можно и так, несущественно. Фокус с `INSTALLED_APPS` уже отработан на практике, а с ready hook надо будет прикинуть, может быть даже сделать автоматическую подгрузку правил.
Попытки разрешить противоречие между безопасностью и удобством с помощью дополнительных инструментов имхо приводит скорее не к поставленной цели, а к возникновению (или усилению) новых, еще не исследованных рисков, которые не заметны на фоне новизны применяемого инструмента.
Так например, FaceID и системы с отпечатком пальца оказываются подвержены подделке с помощью моделирования, менеджер паролей может быть взломан или подменен, а мастер-пароль — забыт или незаметно скомпрометирован, сохраненный локально ключ доступа — украден вирусом, или скачан при временном доступе к физическому хосту со стороны злоумышленника.
Таким образом, кажущаяся удобной защита от одних рисков приводит к возникновению (или усилению) других. Похоже, игра в этом случае таки остается с нулевой суммой, лишь возрастает количество неизвестных.
Но плагин ведь еще поставить надо. Много ли людей поставили себе friGate?
А описанное решение — для тех, кто поленится не то чтобы плагин поставить, а даже поинтересоваться, что это вдруг сайт перестал отвечать…
Без куки не получится закрепить домен за агентом, что приведет к быстрому перебору оператором блокировок всего пула доменов второго уровня.
Не имея возможности обмена куками, мы не сможем (штатными средствами) распознать повторный вход агента оператора блокировок на альтернативный домен и правильным образом редиректить его на его личный URL. Остается только использовать случвйный выбор домена второго уровня, что вероятно, приведет к быстрому исчерпанию пула доменов второго уровня.